"Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
> Michael Nolan wrote:
>> I see one potential difference between your results and mine.
>> When I rebuild the tablespace, I wind up with the same filename/OID as
>> before, I'm not sure you do.
> Right. That's strange.
> Usually OIDs get incremented, so you shouldn't end up with the same
> OID for the new tablespace.
I believe I see what's happening here, and the difference is that
Michael deleted the tablespace's directory while Albe only deleted the
files in it.
The former case causes destroy_tablespace_directories to exit early,
without throwing a hard error, and without having removed the symlink
for the tablespace OID in $PGDATA/pg_tblspc/. This means that after
re-creating a new tablespace in the same directory location, that old
symlink works again, even though it no longer corresponds to any OID in
pg_tablespace. Thus, Michael doesn't see an error in his REINDEX;
physical access to the index still works even though the index's
reltablespace is no longer really valid. The reported symptom of \d
not showing the tablespace is because the code in psql's describe.c will
silently ignore a reltablespace entry that does not match any OID in
pg_tablespace.
We could prevent this scenario if we changed
destroy_tablespace_directories so that for any non-fatal-error
situation, it continues to march on and try to destroy the remaining
infrastructure, particularly the symlink. I'm not sure that's really a
good idea, but it definitely seems to be a bad idea to leave the symlink
in place when we're removing the pg_tablespace row. Alternatively we
could make more of those cases be errors rather than warnings, so that
the pg_tablespace row removal would be rolled back.
The comment in destroy_tablespace_directories indicates that what we're
trying to support by not throwing an error for missing directory is
cleaning up a dead pg_tablespace row, which suggests that removing the
symlink too would be reasonable.
A larger question is whether we should start making pg_shdepend entries
for table/index usage of non-default tablespaces, so that you couldn't
DROP a tablespace that the catalogs think still has tables/indexes in
it. I'm not sure that that'd be particularly helpful though. It
certainly wouldn't do anything to protect against the scenario discussed
here of an external agency zapping all the files.
regards, tom lane