]> granicus.if.org Git - postgresql/commit
Ensure ANALYZE phase is not skipped because of canceled truncate.
authorKevin Grittner <kgrittn@postgresql.org>
Mon, 29 Apr 2013 18:05:26 +0000 (13:05 -0500)
committerKevin Grittner <kgrittn@postgresql.org>
Mon, 29 Apr 2013 18:05:26 +0000 (13:05 -0500)
commit5fc893760f60d57aca30163796db1abe516b3fac
treefc2ccf8b7e8c69f184ff15af4084f14e5df69993
parent91fa8532f4053468acc08534a6aac516ccde47b7
Ensure ANALYZE phase is not skipped because of canceled truncate.

Patch b19e4250b45e91c9cbdd18d35ea6391ab5961c8d attempted to
preserve existing behavior regarding statistics generation in the
case that a truncation attempt was canceled due to lock conflicts.
It failed to do this accurately in two regards: (1) autovacuum had
previously generated statistics if the truncate attempt failed to
initially get the lock rather than having started the attempt, and
(2) the VACUUM ANALYZE command had always generated statistics.

Both of these changes were unintended, and are reverted by this
patch.  On review, there seems to be consensus that the previous
failure to generate statistics when the truncate was terminated
was more an unfortunate consequence of how that effort was
previously terminated than a feature we want to keep; so this
patch generates statistics even when an autovacuum truncation
attempt terminates early.  Another unintended change which is kept
on the basis that it is an improvement is that when a VACUUM
command is truncating, it will the new heuristic for avoiding
blocking other processes, rather than keeping an
AccessExclusiveLock on the table for however long the truncation
takes.

Per multiple reports, with some renaming per patch by Jeff Janes.

Backpatch to 9.0, where problem was created.
src/backend/commands/vacuumlazy.c