Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Jan 15, 2016 at 2:16 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> 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.
> No, you're missing the point, or at least I think you are. Suppose
> somebody creates a big table and then deletes all the tuples in the
> second half, but VACUUM never runs. When at last VACUUM does run on
> that table, it will try to build the VM and FSM forks as it scans the
> table, and will only truncate AFTER that has been done. If building
> the VM and FSM forks fails because there is no freespace, we will
> never reach the part of the operation that could create some.
No, I follow that perfectly. I think you missed *my* point, which is:
suppose that we do have a full-length VM and/or FSM fork for a relation,
and VACUUM decides to truncate the relation. Is it okay to not truncate
the VM/FSM? If it isn't, we're going to have to have very tricky
semantics for any "don't touch the map forks" option, because it will
have to suppress only some of VACUUM's map updates.
If the map invariants are such that leaving garbage in them is
unconditionally safe, then this isn't a problem; but I'm unsure of that.
> The key point is that both the VM and the FSM are optional.
No, the key point is whether it's okay if they *are* there and contain
lies, or self-inconsistent data.
An alternative approach that might avoid such worries is to have a mode
wherein VACUUM always truncates the map forks to nothing, rather than
attempting to update them.
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
