Re: DROP TABLESPACE causes panic during recovery - Mailing list pgsql-hackers

From Tom Lane
Subject Re: DROP TABLESPACE causes panic during recovery
Date
Msg-id 13372.1091674020@sss.pgh.pa.us
Whole thread Raw
In response to Re: DROP TABLESPACE causes panic during recovery  (Kevin Brown <kevin@sysexperts.com>)
Responses Re: DROP TABLESPACE causes panic during recovery
List pgsql-hackers
Kevin Brown <kevin@sysexperts.com> writes:
> Tom Lane wrote:
>> This is impossible to fix nicely because the information to reconstruct
>> the tablespace is simply not available.  We could make an ordinary
>> directory (not a symlink) under pg_tblspc and then limp along in the
>> expectation that it would get removed before we finish replay.  Or we
>> could just skip logged operations on files within the tablespace, but
>> that feels pretty uncomfortable to me --- it amounts to deliberately
>> discarding data ...

> How is a dropped table handled by the recovery code?  Doesn't it present
> the same sort of issues (though on a smaller scale)?

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Andrew Dunstan"
Date:
Subject: Re: Timezone for %t log_line_prefix
Next
From: Gavin Sherry
Date:
Subject: Re: DROP TABLESPACE causes panic during recovery