Re: xlog.c: removing ReadRecPtr and EndRecPtr

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: xlog.c: removing ReadRecPtr and EndRecPtr
Дата
Msg-id 2977886.1637272172@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: xlog.c: removing ReadRecPtr and EndRecPtr  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: xlog.c: removing ReadRecPtr and EndRecPtr  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Nov 18, 2021 at 3:14 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm a little dubious that this test case is valuable enough to
>> mess around with a nonstandard postmaster startup protocol, though.

> The problem that I have with the present situation is that the test
> coverage of xlog.c is pretty abysmal.

Agreed, but this one test case isn't going to move the needle much.
To get to reasonable coverage we're going to need more tests, and
I definitely don't want multiple versions of ad-hoc postmaster startup
code.  If we need that, it'd be smarter to extend Cluster.pm so that
the mainline code could do what's needful.

Having said that, it wasn't entirely clear to me why you needed a
weird startup method.  Why couldn't you drop the bogus history file
into place *before* starting the charlie postmaster?  If you have
to do it after, aren't there race/timing problems anyway?

            regards, tom lane



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

Предыдущее
От: Peter Smith
Дата:
Сообщение: Re: row filtering for logical replication
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Mixing CC and a different CLANG seems like a bad idea