Robert Haas <robertmh...@gmail.com> writes:
> Now, I do think it's a somewhat fair complaint that if you have a
> tablespace which is totally, 100% full, recovery is difficult. You
> can probably DROP the table, but TRUNCATE might fail, and so might
> VACUUM. You could argue that DROP is usually a good substitute for
> TRUNCATE, although there could be dependencies, but DROP is certainly
> not a good substitute for VACUUM. We could address the VACUUM case by
> having an optional argument to VACUUM which tells it to skip VM and
> FSM maintenance, presumably to be used only in case of emergency. I'm
> not sure if it's worth having for what is presumably a pretty rare
> case, but it seems like it could be done.
Presumably the hope would be that VACUUM would truncate off some of the
heap, else there's not much good that's going to happen. That leaves
me wondering exactly what the invariant is for the maps, and if it's
okay to not touch them during a heap truncation.
I believe that there would be ramifications for some of the index AMs
too. For example, if left to its own devices GIN would consider VACUUM
to include flushing its pending-list pages, which more than likely will
increase not reduce the total index size. I'm not sure that it has
any ability to omit that step; can it remove dead entries directly off
the pending pages, or only from the main index?
On the whole this sounds like a lot of work, and a lot of hard-to-test
seldom-exercised code, for a very very narrow corner case.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
