Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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
> 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.
FWIW I notice that RelationTruncate contains an outdated comment at the
top about the 'fsm' function argument which is nowadays no longer an
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
In response to
pgsql-hackers by date
|Next:||From: Florian Weimer||Date: 2010-02-08 19:29:42|
|Subject: Re: Confusion over Python drivers|
|Previous:||From: Tom Lane||Date: 2010-02-08 19:17:15|
|Subject: Re: review: More frame options in window functions |