Re: DROP TABLESPACE causes panic during recovery

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

In response to

Responses

Browse pgsql-hackers by date

  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