Re: DROP TABLESPACE causes panic during recovery - Mailing list pgsql-hackers

From Tom Lane
Subject Re: DROP TABLESPACE causes panic during recovery
Date
Msg-id 13563.1091675277@sss.pgh.pa.us
Whole thread Raw
In response to Re: DROP TABLESPACE causes panic during recovery  (Gavin Sherry <swm@linuxworld.com.au>)
Responses 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>)
List 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 by date:

Previous
From: Gavin Sherry
Date:
Subject: Re: DROP TABLESPACE causes panic during recovery
Next
From: Greg Stark
Date:
Subject: Re: Timezone for %t log_line_prefix