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
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?
Alvaro Herrera alvhe...@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
Tom Lane wrote:
Alvaro Herrera alvhe...@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
Alvaro Herrera wrote:
Tom Lane wrote:
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
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
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
Tom Lane wrote:
Actually, after thinking about this some more, I realize that this code
has got a significantly bigger problem than just whether it will respond
to CANCEL promptly. If we truncate the table, and then get an error
sometime before commit, the relcache inval message will not be
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Actually, after thinking about this some more, I realize that this code
has got a significantly bigger problem than just whether it will respond
to CANCEL promptly.
Err, that problem was exactly why I added the interrupt
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Actually, after thinking about this some more, I realize that this code
has got a significantly bigger problem than just whether it will respond
to CANCEL promptly.
Err, that problem was exactly why I
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Maybe we should do
something about this. There wasn't any obvious solution before,
but now that we have the nontransactional smgr-level sinval messages
being sent on drops and truncates, it seems like tying rd_targblock
10 matches
Mail list logo
