Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Tom Lane wrote:
> >> I see that lazy_vacuum_rel() truncates the heap before it does vacuuming
> >> of the free space map. Once upon a time this wouldn't have mattered,
> >> but now it means that cancel interrupts are likely to be ignored for
> >> the duration of FreeSpaceMapVacuum(). Is that really necessary?
> >> Would it be okay to swap the two steps?
>
> > How would it matter? Interrupts are not enabled until the transaction
> > is committed anyway, which must happen after both things have finished ..
>
> The point would be to not disable interrupts till after doing the FSM
> vacuuming. Ignoring CANCEL for longer than we must is bad.
Oh, I see. I guess the answer is that it depends on what happens if you
interrupt after vacuuming the FSM. I have no idea what that is supposed
to accomplish so I'm of no help here. FreeSpaceMapVacuum says it's
about fixing inconsistencies in the FSM, so I'm guessing that it's not
critical.
> I'm also looking at not disabling the interrupt until lazy_truncate_heap
> determines that it's actually going to do RelationTruncate. The current
> coding disables interrupts without any need in a large fraction of cases.
Hmm, yeah ... that moves the code to the innards of lazy_truncate_heap.
Seems reasonable.
FWIW I notice that RelationTruncate contains an outdated comment at the
top about the 'fsm' function argument which is nowadays no longer an
argument.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support