Re: xlog.c: removing ReadRecPtr and EndRecPtr

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amul Sul <sulamul(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: xlog.c: removing ReadRecPtr and EndRecPtr
Date: 2021-11-18 21:49:32
Message-ID: 2977886.1637272172@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Nov 18, 2021 at 3:14 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-11-18 21:57:52 Re: Mixing CC and a different CLANG seems like a bad idea
Previous Message Peter Smith 2021-11-18 21:46:18 Re: row filtering for logical replication