Обсуждение: BUG #8954: Wrong text in database log during "truncate scan"

Поиск
Список
Период
Сортировка

BUG #8954: Wrong text in database log during "truncate scan"

От
maxim.boguk@gmail.com
Дата:
The following bug has been logged on the website:

Bug reference:      8954
Logged by:          Maksym
Email address:      maxim.boguk@gmail.com
PostgreSQL version: 9.2.4
Operating system:   Linux
Description:

Hi,

If manual vacuum performed in the table and could not required lock for
truncate scan it wrote a bit misleading error message:

2014-01-24 16:19:11 MSK 7134 cron.app@*** from [local] [vxid:297/14422865
txid:2179070646] [VACUUM] LOG:  automatic vacuum of table
"hh_data.public.vacancy_response": could not (re)acquire exclusive lock for
truncate scan
2014-01-24 16:19:11 MSK 7134 cron.app@*** from [local] [vxid:297/14422865
txid:2179070646] [VACUUM] STATEMENT:  VACUUM public.vacancy_response
2014-01-24 16:19:11 MSK 7134 cron.app@*** from [local] [vxid:297/0 txid:0]
[VACUUM] LOG:  duration: 589175.931 ms  statement: VACUUM
public.vacancy_response


Please note "automatic vacuum of table".
It was definitely not autovacuum but manual vacuum run.

Re: BUG #8954: Wrong text in database log during "truncate scan"

От
Alvaro Herrera
Дата:
maxim.boguk@gmail.com escribió:

> If manual vacuum performed in the table and could not required lock for
> truncate scan it wrote a bit misleading error message:
>
> 2014-01-24 16:19:11 MSK 7134 cron.app@*** from [local] [vxid:297/14422865
> txid:2179070646] [VACUUM] LOG:  automatic vacuum of table
> "hh_data.public.vacancy_response": could not (re)acquire exclusive lock for
> truncate scan

This was fixed by this commit:

Author: Kevin Grittner <kgrittn@postgresql.org>
Branch: master Release: REL9_3_BR [5fc893760] 2013-04-29 13:05:26 -0500
Branch: REL9_2_STABLE Release: REL9_2_5 [95909f3be] 2013-04-29 13:05:56 -0500
Branch: REL9_1_STABLE Release: REL9_1_10 [93641341f] 2013-04-29 13:06:28 -0500
Branch: REL9_0_STABLE Release: REL9_0_14 [2751c7f73] 2013-04-29 13:06:49 -0500

    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.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services