Re: WAL replay of truncate fails if the table was dropped
От | Heikki Linnakangas |
---|---|
Тема | Re: WAL replay of truncate fails if the table was dropped |
Дата | |
Msg-id | 46A0D3C3.3070507@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: WAL replay of truncate fails if the table was dropped (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WAL replay of truncate fails if the table was dropped
|
Список | 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 по дате отправления: