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 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.
Err, that problem was exactly why I added the interrupt holdoff in there, so if you've got a better/more invasive solution, it's very welcome. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
