Alvaro Herrera <alvherre@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 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.
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 sent,
leaving other backends at significant risk of strange errors due to
having rd_targblock pointing somewhere past the end of the table.
So we should reorder these operations just to reduce the risk window,
and I've done so.
It might be a good idea to develop a nontransactional signaling method
for causing other backends to reset rd_targblock --- perhaps we could
tie it to the smgr inval signaling that already happens on a truncate?
That would probably require moving rd_targblock down to the smgr
level, but offhand I see no reason that that'd be a bad thing to do.
I'm not going to panic about it right now, since the code has been like
this for a long time and we've had few if any complaints. But it seems
like something to fix sometime.
regards, tom lane
