Re: DROP TABLESPACE causes panic during recovery
От | Tom Lane |
---|---|
Тема | Re: DROP TABLESPACE causes panic during recovery |
Дата | |
Msg-id | 13372.1091674020@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: DROP TABLESPACE causes panic during recovery (Kevin Brown <kevin@sysexperts.com>) |
Ответы |
Re: DROP TABLESPACE causes panic during recovery
|
Список | pgsql-hackers |
Kevin Brown <kevin@sysexperts.com> writes: > Tom Lane wrote: >> This is impossible to fix nicely because the information to reconstruct >> the tablespace is simply not available. We could make an ordinary >> directory (not a symlink) under pg_tblspc and then limp along in the >> expectation that it would get removed before we finish replay. Or we >> could just skip logged operations on files within the tablespace, but >> that feels pretty uncomfortable to me --- it amounts to deliberately >> discarding data ... > How is a dropped table handled by the recovery code? Doesn't it present > the same sort of issues (though on a smaller scale)? Not really. If the replay code encounters an update to a table file that's not there, it simply creates the file and plows ahead. The thing that I'm stuck on about tablespaces is that if the symlink in $PGDATA/pg_tblspc isn't there, there's no evident way to recreate it correctly --- we have no idea where it was supposed to point. regards, tom lane
В списке pgsql-hackers по дате отправления: