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
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 |