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

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: WAL replay of truncate fails if the table was dropped
Date: 2007-07-20 15:24:51
Message-ID: 46A0D3C3.3070507@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2007-07-20 15:38:07 Re: WAL replay of truncate fails if the table was dropped
Previous Message Tom Lane 2007-07-20 15:12:19 Re: WAL replay of truncate fails if the table was dropped