Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1azthY-0002ik-4l for pgsql-admin@arkaria.postgresql.org; Mon, 09 May 2016 22:30:56 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1azthX-0006x0-O7 for pgsql-admin@arkaria.postgresql.org; Mon, 09 May 2016 22:30:55 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1azthX-0006wX-7Z for pgsql-admin@postgresql.org; Mon, 09 May 2016 22:30:55 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1azthU-0004rk-JQ for pgsql-admin@postgresql.org; Mon, 09 May 2016 22:30:54 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u49MUlqA004024; Mon, 9 May 2016 18:30:47 -0400 From: Tom Lane To: Alvaro Herrera cc: =?utf-8?B?T25kxZllaiBTdsSbdGzDrWs=?= , pgsql-admin@postgresql.org Subject: Re: Autovacuum of pg_database In-reply-to: <20160509213030.GA496423@alvherre.pgsql> References: <20160509213030.GA496423@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Mon, 09 May 2016 18:30:30 -0300" Date: Mon, 09 May 2016 18:30:47 -0400 Message-ID: <4023.1462833047@sss.pgh.pa.us> X-Pg-Spam-Score: -4.0 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org Alvaro Herrera 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. 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