From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kevin Brown <kevin(at)sysexperts(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: DROP TABLESPACE causes panic during recovery |
Date: | 2004-08-05 02:47:00 |
Message-ID: | 13372.1091674020@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kevin Brown <kevin(at)sysexperts(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Sherry | 2004-08-05 03:01:46 | Re: DROP TABLESPACE causes panic during recovery |
Previous Message | Andrew Dunstan | 2004-08-05 02:41:04 | Re: Timezone for %t log_line_prefix |