Re: prevent immature WAL streaming - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: prevent immature WAL streaming
Date
Msg-id 202109212119.c3nhfp64t2ql@alvherre.pgsql
Whole thread Raw
In response to Re: prevent immature WAL streaming  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: prevent immature WAL streaming
List pgsql-hackers
I made one final pass over the whole thing to be sure it's all commented
as thoroughly as possible, and changed the names of things to make them
all consistent.  So here's the last version which I intend to push to
all branches soon.  (The only difference in back-branches is that
the xlogreader struct needs to be adjusted to have the new fields at the
bottom.)

One thing to note is that this is an un-downgradeable minor; and of
course people should upgrade standbys before primaries.

On 2021-Sep-17, Alvaro Herrera wrote:

> On 2021-Sep-17, Bossart, Nathan wrote:

> > I see.  IMO feels a bit counterintuitive to validate a partial record
> > that you are ignoring anyway, but I suppose it's still valuable to
> > know when the WAL is badly broken.  It's not expensive, and it doesn't
> > add a ton of complexity, either.
> 
> Yeah, we don't have any WAL record history validation other than the
> verifying the LSN of the previous record; I suppose in this particular
> case you could argue that we shouldn't bother with any validation
> either.  But it seems safer to do it.  It doesn't hurt anything anyway.

BTW we do validate the CRC for all records, but we don't have any means
to validate the CRC of a partial record; so in theory if we don't add
CRC validation of the ignored contents, there would be no validation at
all for that record.  I don't think we care, but it's true that there
would be a big blob in WAL that we don't really know anything about.

-- 
Álvaro Herrera              Valdivia, Chile  —  https://www.EnterpriseDB.com/
Thou shalt study thy libraries and strive not to reinvent them without
cause, that thy code may be short and readable and thy days pleasant
and productive. (7th Commandment for C Programmers)

Attachment

pgsql-hackers by date:

Previous
From: Jeremy Schneider
Date:
Subject: Re: relation OID in ReorderBufferToastReplace error message
Next
From: Thomas Munro
Date:
Subject: Re: PostgreSQL High Precision Support Extension.