From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: =?utf-8?B?T25kxZllaiBTdsSbdGzDrWs=?= <osvetlik@flexibee.eu>,
        pgsql-admin@postgresql.org
Subject: Re: Autovacuum of pg_shdepend
In-reply-to: <20160504152518.GA102195@alvherre.pgsql>
References: <20160504152518.GA102195@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Wed, 04 May 2016 12:25:18 -0300"
Date: Wed, 04 May 2016 15:07:07 -0400
Message-ID: <17376.1462388827@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

Alvaro Herrera <alvherre@2ndquadrant.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


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin