Re: WAL replay of truncate fails if the table was dropped

Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Interestingly, this bug isn't triggered unless there's an already empty
> or uninitialized page at the end of table. If vacuum removes the last
> tuple from the page, that will be WAL-logged and replay of that calls
> smgrcreate.

Yeah, I tried other ways to provoke the failure and came to the same
conclusion. The reproducer really is relying on the fact that vacuum's
PageInit of an uninitialized page doesn't get WAL-logged. Which is a
bit nervous-making. As far as I can think at the moment, it won't
provoke any problem because the first subsequent WAL-logged touch of
the page would be an INSERT with the INIT bit set; but it does mean
that a warm-standby slave would be out of sync with the master for an
indefinitely long period with respect to the on-disk contents of such a
page. Does that matter?

Note that we have to fix truncate replay anyway, since you could have
the same failure if a checkpoint happened just before an ordinary
vacuum's truncate. This PageInit behavior merely allows a simpler
reproducer script with no race condition involved.

regards, tom lane