Re: WAL replay of truncate fails if the table was dropped - Mailing list pgsql-bugs

From Heikki Linnakangas
Subject Re: WAL replay of truncate fails if the table was dropped
Date
Msg-id 46A0D3C3.3070507@enterprisedb.com
Whole thread Raw
In response to Re: WAL replay of truncate fails if the table was dropped  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WAL replay of truncate fails if the table was dropped  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
>> mdtruncate throws an error if the relation file doesn't exist.
>
> Interesting corner case.  The proposed fix seems not very consistent
> with the way we handle comparable cases elsewhere, though.  In general,
> md.c will cut some slack when InRecovery if a relation is shorter than
> expected, but not if it's not there at all.  (This is, indeed, what
> justifies mdtruncate's response to file-too-short...)  We handle
> dropped files during recovery by forced smgrcreate() in places like
> XLogOpenRelation.  I'm inclined to think smgr_redo should force
> smgrcreate() before trying to truncate.

I followed the example of the file-too-short case. Yeah, calling
smgrcreate would work and I can see the justification for that as well.

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.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: WAL replay of truncate fails if the table was dropped
Next
From: Tom Lane
Date:
Subject: Re: WAL replay of truncate fails if the table was dropped