On Fri, Jan 10, 2020 at 05:01:25PM +0900, Michael Paquier wrote:
> This makes me wonder how much we should try to outsmart somebody which
> puts the catalogs in such a inconsistent state. Hmm. Perhaps at the
> end autovacuum should just ignore such entries and just don't help the
> user at all as this also comes with its own issues with the storage
> level as well as smgr.c uses rd_backend. And if the user plays with
> temporary namespaces like that with superuser rights, he likely knows
> what he is doing. Perhaps not :D, in which case autovacuum may not be
> the best thing to decide that. I still think we should make the log
> of autovacuum.c for orphaned relations more careful with its coding
> though, and fix it with the previous patch. The documentation of
> isTempNamespaceInUse() could gain in clarity, just a nit from me while
> looking at the surroundings. And actually I found an issue with its
> logic, as the routine would not consider a temp namespace in use for a
> session's own MyBackendId. As that's only used for autovacuum, this
> has no consequence, but let's be correct in hte long run.
>
> And this gives the attached after a closer lookup. Thoughts?
Thinking more about it, this has a race condition if a temporary
schema is removed after collecting the OIDs in the drop phase. So the
updated attached is actually much more conservative and does not need
an update of the log message, without giving up on the improvements
done in v11~. In 9.4~10, the code of the second phase relies on
GetTempNamespaceBackendId() which causes an orphaned relation to not
be dropped in the event of a missing namespace. I'll just leave that
alone for a couple of days now..
--
Michael