From: Noah Misch <noah@leadboat.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: thomas.munro@gmail.com
Cc: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17928: Standby fails to decode WAL on termination of primary
Date: Fri, 11 Aug 2023 07:00:08 -0700
Message-ID: <20230811140008.GB2261449@rfd.leadboat.com> (raw)
In-Reply-To: <ZNXQWvnmt1Fpt6vu@paquier.xyz>
References: <72bd036d-4f2a-8d50-b56e-6b1e3b9ba0a9@gmail.com>
<CA+hUKG+t8gfYBS2TRMW6rHaWUBEC1Cy+p-0pgPBx8ag8TBeoKw@mail.gmail.com>
<20230710200012.GB3476234@rfd.leadboat.com>
<20230711.155414.939136339819647605.horikyota.ntt@gmail.com>
<20230717004905.GE3826297@rfd.leadboat.com>
<ZNSVlR/v8gTDIMsU@paquier.xyz>
<20230811025808.GA2261232@rfd.leadboat.com>
<ZNXQWvnmt1Fpt6vu@paquier.xyz>
On Fri, Aug 11, 2023 at 03:08:26PM +0900, Michael Paquier wrote:
> On Thu, Aug 10, 2023 at 07:58:08PM -0700, Noah Misch wrote:
> > On Thu, Aug 10, 2023 at 04:45:25PM +0900, Michael Paquier wrote:
> >> Good idea to pollute the data with recycled segments. Using a minimal
> >> WAL segment size whould help here as well in keeping a test cheap, and
> >> two segments should be enough. The alignment calculations and the
> >> header size can be known, but the standby records are an issue for the
> >> predictability of the test when it comes to adjust the length of the
> >> logical message depending on the 8k WAL page, no?
> >
> > Could be. I expect there would be challenges translating that outline into a
> > real test, but I don't know if that will be a major one. The test doesn't
> > need to be 100% deterministic. If it fails 25% of the time and is not the
> > slowest test in the recovery suite, I'd find that good enough.
>
> FWIW, I'm having a pretty hard time to get something close enough to a
> page border in a reliable way. Perhaps using a larger series of
> records and select only one would be more reliable.. Need to test
> that a bit more.
Interesting. So pg_logical_emit_message(false, 'X', repeat('X', n)) doesn't
get close enough, but s/n/n+1/ spills to the next page? If so, I did not
anticipate that.
> >> FWIW, I came back to this thread while tweaking the error reporting of
> >> xlogreader.c for the sake of this thread and this proposal is an
> >> improvement to be able to make a distinction between an OOM and an
> >> incorrect record:
> >> https://www.postgresql.org/message-id/ZMh/WV+CuknqePQQ@paquier.xyz
> >>
> >> Anyway, agreed that it's an improvement to remove this check out of
> >> allocate_recordbuf(). Noah, are you planning to work more on that?
> >
> > I can push xl_tot_len-validate-v1.patch, particularly given the testing result
> > you reported today. I'm content for my part to stop there.
>
> Okay, fine by me. That's going to help with what I am doing in the
> other thread as I'd need to make a better difference between the OOM
> and the invalid cases for the allocation path.
>
> You are planning for a backpatch to take care of the inconsistency,
> right? The report has been on 15~ where the prefetching was
> introduced. I'd be OK to just do that and not mess up with the stable
> branches more than necessary (aka ~14) if nobody complains, especially
> REL_11_STABLE planned to be EOL'd in the next minor cycle.
I recall earlier messages theorizing that it was just harder to hit in v14, so
I'm disinclined to stop at v15. I think the main choice is whether to stop at
v11 (normal choice) or v12 (worry about breaking the last v11 point release).
I don't have a strong opinion between those.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: noah@leadboat.com, michael@paquier.xyz, horikyota.ntt@gmail.com, thomas.munro@gmail.com, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17928: Standby fails to decode WAL on termination of primary
In-Reply-To: <20230811140008.GB2261449@rfd.leadboat.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox