From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, swm(at)linuxworld(dot)com(dot)au, kevin(at)sysexperts(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: DROP TABLESPACE causes panic during recovery |
Date: | 2004-08-05 04:01:12 |
Message-ID: | 200408050401.i7541Cn21636@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan wrote:
> Tom Lane said:
> >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.
> >
>
> Could we create the tables in the default tablespace? Or create a dummy
> tablespace (since it's not there we expect it to be removed anyway, don't
> we?) I guess the big danger would be running out of disk space, but maybe
> that is a lower risk than this one.
Uh, why is the symlink not going to be there already?
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2004-08-05 04:07:39 | Re: [BUGS] casting strings to multidimensional arrays yields strange |
Previous Message | Greg Stark | 2004-08-05 03:55:58 | Re: DROP TABLESPACE causes panic during recovery |