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

From Amul Sul
Subject Re: xlog.c: removing ReadRecPtr and EndRecPtr
Date
Msg-id CAAJ_b94LJNAb=B3CSBiPhjm9mtpWP7FgBjhLVikXU_f4wiip_w@mail.gmail.com
Whole thread Raw
In response to Re: xlog.c: removing ReadRecPtr and EndRecPtr  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Nov 19, 2021 at 12:43 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Nov 18, 2021 at 7:30 AM Amul Sul <sulamul@gmail.com> wrote:
> > Somehow with and without patch I am getting the same log.
>
> Try applying the attached 0001-dubious-test-cast.patch for you and see
> if that fails. It does for me. If so, then try applying
> 0002-fix-the-bug.patch and see if that makes it pass.
>

Thanks,  I can see the reported behavior -- 0001 alone fails & 0002
corrects that.

> Unfortunately, this test case isn't remotely committable as-is, and I
> don't know how to make it so. The main problem is that, although you
> can start up a server with nothing in pg_wal, no restore_command, and
> no archive command, pg_ctl will not believe that it has started. I
> worked around that problem by telling pg_ctl to ignore failures, but
> it still waits for a long time before timing out, which sucks both
> because (1) hackers are impatient and (2) some hackers run extremely
> slow buildfarm machines where almost any timeout won't be long enough.

Yeah :(

> There's a second place where the patch needs to wait for something
> also, and that one I've crudely kludged with sleep(10). If anybody
> around here who is good at figuring out how to write clever TAP tests
> can tell me how to fix this test to be non-stupid, I will happily do
> so.
>
> Otherwise, I think I will just need to commit and back-patch the
> actual bug fix without a test, and then rebase the rest of the patch I
> posted previously over top of those changes for master only.
>

+1.

Regards,
Amul



pgsql-hackers by date:

Previous
From: Jeevan Ladhe
Date:
Subject: Re: Teach pg_receivewal to use lz4 compression
Next
From: Richard Guo
Date:
Subject: Re: A spot of redundant initialization of brin memtuple