I had the same problem with 9.1 and vacuuming several databases simultaneously. We just lived with it. Other tables in the databases were far larger than pg_sharedepend, so it wasn't the most significant issue we faced. Bob Lunney > On May 9, 2016, at 6:42 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > > I wrote: >> Alvaro Herrera <alvherre@xxxxxxxxxxxxxxx> 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 > > > -- > Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
