From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Ondřej Světlík <osvetlik(at)flexibee(dot)eu>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Autovacuum of pg_database |
Date: | 2016-05-09 22:42:26 |
Message-ID: | 4352.1462833746@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
I wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> Now that I actually tried this, it turned out that this problem is not
>> so simple. vacuum.c already has logic to use conditional acquire of the
>> table-level lock, and if not available it skips the table:
>> LOG: skipping vacuum of "pg_shdepend" --- lock not available
>> so an autovacuum worker is never "stuck" behind another worker trying to
>> vacuum the table.
> Hmm ... but then, how do we have the observed symptom of several workers
> concurrently trying to process the same shared catalog? Seems like all
> but one should fall out at this point.
Oh, see table_recheck_autovac:
tab->at_vacoptions = VACOPT_SKIPTOAST |
(dovacuum ? VACOPT_VACUUM : 0) |
(doanalyze ? VACOPT_ANALYZE : 0) |
(!wraparound ? VACOPT_NOWAIT : 0);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'll bet they're all trying to do anti-wraparound vacuums. This would
explain why the problem hasn't been observed often enough to have been
fixed long since.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | drum.lucas@gmail.com | 2016-05-09 22:59:45 | toast tables |
Previous Message | Tom Lane | 2016-05-09 22:30:47 | Re: Autovacuum of pg_database |