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_shdepend |
Date: | 2016-05-04 19:07:07 |
Message-ID: | 17376.1462388827@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Ooh, interesting bug.
> As a workaround I suggest connecting to all of your databases except one
> and disabling autovacuum for pg_shdepend. Then the table will be
> processed in the one database where you left it enabled, and the other
> workers will take care of the rest of the tables.
> I'll think about a real fix.
Seems like a simple answer is to consider all shared catalogs to "belong"
to only one database for autovac purposes, ie, only autovac workers in
that database would consider vacuuming them. The problem IIUC is that the
interlock against multiple workers glomming onto the same table only
considers other workers in the same DB.
The fun part might be to decide which DB that is. I don't think we should
depend on any of the standard databases always being there.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ondřej Světlík | 2016-05-04 19:09:07 | Re: Autovacuum of pg_shdepend |
Previous Message | Victor Yegorov | 2016-05-04 18:52:04 | Re: Autovacuum of pg_shdepend |