Re: Implement generalized sub routine find_in_log for tap test

Поиск
Список
Период
Сортировка
От vignesh C
Тема Re: Implement generalized sub routine find_in_log for tap test
Дата
Msg-id CALDaNm2TK623jrGQomqwH1JFd8DdFSa9epoZJf279AXb1S2GGQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Implement generalized sub routine find_in_log for tap test  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Implement generalized sub routine find_in_log for tap test  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Tue, 6 Jun 2023 at 09:36, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Jun 06, 2023 at 08:05:49AM +0530, Amit Kapila wrote:
> > Personally, I don't see any problem to do this refactoring for v16.
> > However, sometimes, we do decide to backpatch refactoring in tests to
> > avoid backpatch effort. I am not completely sure if that is the case
> > here.
>
> 033_replay_tsp_drops.pl has one find_in_log() down to 11, and
> 019_replslot_limit.pl has four calls down to 14.  Making things
> consistent everywhere is a rather appealing argument to ease future
> backpatching.  So I am OK to spend a few extra cycles in adjusting
> these routines all the way down where needed.  I'll do that tomorrow
> once I get back in front of my laptop.
>
> Note that connect_ok() and connect_fails() are new to 14, so this
> part has no need to go further down than that.

Please find the attached patches that can be applied on back branches
too. v5*master.patch can be applied on master, v5*PG15.patch can be
applied on PG15, v5*PG14.patch can be applied on PG14, v5*PG13.patch
can be applied on PG13, v5*PG12.patch can be applied on PG12, PG11 and
PG10.

Regards,
Vignesh

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Daniel Verite"
Дата:
Сообщение: Re: Order changes in PG16 since ICU introduction
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Let's make PostgreSQL multi-threaded