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

On Fri, 2007-07-20 at 11:38 -0400, Tom Lane wrote:
> 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?

If I understand this: the primary would be initialised yet the standby
would remain uninitialised? I don't think that matters because the
actual the data contents are still zero.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com