From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: DROP TABLESPACE causes panic during recovery |
Date: | 2004-08-05 03:55:58 |
Message-ID: | 87wu0ei6gh.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
> > CREATE TABLESPACE
> > ...
> > much time passes
> > ...
> > CHECKPOINT
> > ...
> > modify tables in tablespace
> > drop tables in tablespace
> > DROP TABLESPACE
> > ...
> > system crash
What happens here if no table spaces are involved?
It just creates bogus tables with partial data counting on the restore to see
the drop table command later and delete the corrupt tables?
Does that pose any danger with PITR? The scenario above seems ok since if the
PITR starting point is after the drop table/tablespace then presumably the
recovery target has to be after that as well? Is there any other scenario
where the partial data files could escape the recovery process?
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-08-05 04:01:12 | Re: DROP TABLESPACE causes panic during recovery |
Previous Message | Tom Lane | 2004-08-05 03:51:58 | Re: [BUGS] casting strings to multidimensional arrays yields strange results |