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: | Whole Thread | Raw Message | 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
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 |