Re: DROP TABLESPACE causes panic during recovery

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: DROP TABLESPACE causes panic during recovery
Дата
Msg-id 13563.1091675277@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: DROP TABLESPACE causes panic during recovery  (Gavin Sherry <swm@linuxworld.com.au>)
Ответы Re: DROP TABLESPACE causes panic during recovery  (Gavin Sherry <swm@linuxworld.com.au>)
Re: DROP TABLESPACE causes panic during recovery  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: DROP TABLESPACE causes panic during recovery  ("Andrew Dunstan" <andrew@dunslane.net>)
Список pgsql-hackers
Gavin Sherry <swm@linuxworld.com.au> writes:
> On Wed, 4 Aug 2004, Tom Lane wrote:
>> 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?

We do need to do that, but it will *not* solve this problem.  The
scenario that causes the problem is
CREATE TABLESPACE...much time passes...CHECKPOINT...modify tables in tablespacedrop tables in tablespaceDROP
TABLESPACE...systemcrash
 

Now the system needs to replay from the last checkpoint.  It's going to
hit updates to tables that aren't there anymore in a tablespace that's
not there anymore.  There will not be anything in the replayed part of
the log that will give a clue where that tablespace was physically.
        regards, tom lane


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

Предыдущее
От: Gavin Sherry
Дата:
Сообщение: Re: DROP TABLESPACE causes panic during recovery
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Timezone for %t log_line_prefix