Re: DROP TABLESPACE causes panic during recovery

On Wed, 4 Aug 2004, Tom Lane wrote:

> 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.

Ahh, yes of course.

Seems like the best way would be to create the path under pg_tblspc as
directories and plough ahead, like you said. The only alternatively that
comes to mind is that we could keep all the directory structure and
symlinks around until the next checkpoint. But that would be messy and may
well not solve the problem anyway for things like PITR.

Gavin