Horton

Re: Corruption during WAL replay

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, tejeswarm@hotmail.com, Andres Freund <andres@anarazel.de>, hlinnaka <hlinnaka@iki.fi>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Daniel Wood <hexexpert@comcast.net>
Date: 2021-09-24T19:37:51Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> I like this patch.

I think the basic idea is about right, but I'm not happy with the
three-way delayChkpt business; that seems too cute by three-quarters.
I think two independent boolean flags, one saying "I'm preventing
checkpoint start" and one saying "I'm preventing checkpoint completion",
would be much less confusing and also more future-proof.  Who's to say
that we won't ever need both states to be set in the same process?

I also dislike the fact that the patch has made procarray.h depend
on proc.h ... maybe I'm wrong, but I thought that there was a reason
for keeping those independent, if indeed this hasn't actually resulted
in a circular-includes situation.  If we avoid inventing that enum type
then there's no need for that.  If we do need an enum, maybe it could
be put in some already-common prerequisite header.

			regards, tom lane

Commits

  1. Harden TAP tests that intentionally corrupt page checksums.

  2. Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.

  3. Remember to reset yy_start state when firing up repl_scanner.l.