Re: DROP TABLESPACE causes panic during recovery

Поиск
Список
Период
Сортировка
От Gavin Sherry
Тема Re: DROP TABLESPACE causes panic during recovery
Дата
Msg-id Pine.LNX.4.58.0408051301110.6663@linuxworld.com.au
обсуждение исходный текст
Ответ на Re: DROP TABLESPACE causes panic during recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: DROP TABLESPACE causes panic during recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, 4 Aug 2004, Tom Lane wrote:

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

I don't think we have any choice but to log the symlink creation. Will
this solve the problem?

Gavin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: DROP TABLESPACE causes panic during recovery
Следующее
От: Tom Lane
Дата:
Сообщение: Re: DROP TABLESPACE causes panic during recovery