Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bUijI-0004x5-F6 for pgsql-admin@arkaria.postgresql.org; Tue, 02 Aug 2016 23:04:08 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bUijH-0007I8-A1 for pgsql-admin@arkaria.postgresql.org; Tue, 02 Aug 2016 23:04:07 +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 1bUihZ-0003xF-7H for pgsql-admin@postgresql.org; Tue, 02 Aug 2016 23:02:21 +0000 Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bUihR-0002sC-0M for pgsql-admin@postgresql.org; Tue, 02 Aug 2016 23:02:19 +0000 Received: by mail-wm0-x235.google.com with SMTP id i5so311051213wmg.0 for ; Tue, 02 Aug 2016 16:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=flexibee-eu.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=D8IBExCVdB4mG+qg1LAbs5rRdBdTfToxxHug3caKIFs=; b=EI0CxcgzroF1VdrGLzfM6xXtS9+zXHO75T6xgoRlzZDhTdiIWSUTq1jC5YD6PRVCZO GX3IwMqufXTPl4/WVhvnD+iWvqp/HgSk9b2+wW8dtB5b5WMzHm8jlVzC2E13jRu0lV+4 UZe6ZvLeS+d8BRXvWcFvH7zEL0WN8s7nQv3IT3kt4bury4hN9JSE8TG/ii/BUBHXpHF+ Law4LhrrtaqtJWOWzl5n3w95KFN5d1WwaQ5POMPVayJbDtqcekpa3uq9PbRcjtYw+S3b prMkGn+fDGFccpMj3TThSsvO/oNDR9Z2JSzxfySq89xwQ8o71qLzkE16lfBunRD0vjk6 4z5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=D8IBExCVdB4mG+qg1LAbs5rRdBdTfToxxHug3caKIFs=; b=SQCfLYr1m7wtuciYUtZbyVjYWO1u9d6XZkUEG6T4r4Lvf0Z3fBkPCqCY0LRFfbgahU lEDkYUB+CALtEM6tF7wx65/01VqAVLrhPWgkfdDsFZRUjjF1Tu/4wmr3qK7T8Xfb4zvZ QO3rKHoUZzJweeuztKvLnQM47TWGOzfgzJ5ulOzC6JmVqxn2a9i+7kmMuNrRc3L36wsF EGHDECALfO/0J1iZMErJLC4DT2vBmu6P4DJZaYrL26DI1fOeSde59BbX/GWA97Gtvj/w FSgstASvfe7P4eMZzd/waRXUYNUzuSEQDjDsA+5xTDrzkaf7UTNs4Wzm3VqehQCypMbF 3UGw== X-Gm-Message-State: AEkoout0lM5QbsUDdctzGNDVdMn3CCBFp2oeAYTXn3i3zXWfTIXi8AMi6VYmPdYvvabDwpyh X-Received: by 10.194.164.9 with SMTP id ym9mr56195750wjb.78.1470178930093; Tue, 02 Aug 2016 16:02:10 -0700 (PDT) Received: from osvetlik.home ([77.48.30.240]) by smtp.gmail.com with ESMTPSA id a2sm4659341wjg.46.2016.08.02.16.02.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Aug 2016 16:02:08 -0700 (PDT) Subject: Re: Autovacuum of pg_shdepend To: pgsql-admin@postgresql.org References: <572A1072.5080308@flexibee.eu> <572A56B9.1020202@flexibee.eu> From: =?UTF-8?B?T25kxZllaiBTdsSbdGzDrWs=?= Message-ID: Date: Wed, 3 Aug 2016 01:02:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <572A56B9.1020202@flexibee.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Pg-Spam-Score: -2.6 (--) 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 Dne 4.5.2016 v 22:08 Ondřej Světlík napsal(a): > Dne 4.5.2016 v 20:52 Victor Yegorov napsal(a): >> 2016-05-04 18:08 GMT+03:00 Ondřej Světlík > >: >> >> we have a strange problem with autovacuum. We have three workers, >> but usually only one works and two are waiting as they are all >> trying to process table pg_shdepend which is shared between all >> databases. >> >> >> I hit the same issue when we've migrated out all large objects (~200Gb >> total), I've executed `vacuumlo` and then all autovacuums started to >> process `pg_shdepend`. >> They've been picking on this table over and over again from different >> databases, but were stopping on the truncation phase due to other >> autovacuums were waiting on the same table. >> >> I ended up manually vacuuming this table in the database, that was >> cleaned up, and also in the `postgres` DB. It fixed the case for me. >> This was on 9.0.23 though. >> >> -- >> Victor Y. Yegorov > > Thank you very much, we have a working autovacuum on one of our clusters > again. That's awesome :-). > > Ondřej Hello again, as this is still not fixed in any released version and the problem occurred again, let me ask one question. Which form of manual VACUUM is sufficient to prevent wraparound? Is it VACUUM FREEZE or do I have to use VACUUM FULL? Thanks in advance, Ondřej -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin