Re: DROP TABLESPACE causes panic during recovery

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
Cc: Kevin Brown <kevin(at)sysexperts(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: DROP TABLESPACE causes panic during recovery
Date: 2004-08-05 03:07:57
Message-ID: 13563.1091675277@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gavin Sherry <swm(at)linuxworld(dot)com(dot)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 tablespace
drop tables in tablespace
DROP TABLESPACE
...
system crash

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2004-08-05 03:17:23 Re: Timezone for %t log_line_prefix
Previous Message Gavin Sherry 2004-08-05 03:01:46 Re: DROP TABLESPACE causes panic during recovery