Re: xlog.c: removing ReadRecPtr and EndRecPtr - Mailing list pgsql-hackers

From Tom Lane
Subject Re: xlog.c: removing ReadRecPtr and EndRecPtr
Date
Msg-id 2977886.1637272172@sss.pgh.pa.us
Whole thread Raw
In response to Re: xlog.c: removing ReadRecPtr and EndRecPtr  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: xlog.c: removing ReadRecPtr and EndRecPtr
List 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 by date:

Previous
From: Peter Smith
Date:
Subject: Re: row filtering for logical replication
Next
From: Tom Lane
Date:
Subject: Re: Mixing CC and a different CLANG seems like a bad idea