Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gfE5g-0003NV-Gr for pgsql-admin@arkaria.postgresql.org; Fri, 04 Jan 2019 01:16:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gfE5d-0004Bf-Kt for pgsql-admin@arkaria.postgresql.org; Fri, 04 Jan 2019 01:15:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gfE5d-0004BY-6R for pgsql-admin@lists.postgresql.org; Fri, 04 Jan 2019 01:15:57 +0000 Received: from mail-qk1-x744.google.com ([2607:f8b0:4864:20::744]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gfE5Z-0000ay-FL for pgsql-admin@lists.postgresql.org; Fri, 04 Jan 2019 01:15:55 +0000 Received: by mail-qk1-x744.google.com with SMTP id z18so4766187qkj.10 for ; Thu, 03 Jan 2019 17:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=xdHl/etckiQR9elD+uCN1KU5yBbkzeqp6P+9xsk6lvk=; b=ajTSBLjwoSNyVXZ1VN9kmoMVLtIFWPeunhYcHZ5YS00x+v/gT9HkY7ERDklH2+Bx7h PCWU0Gngltf11rCsZQM5elJzE1aVEOeJDXiugi+5AXKuq1x1716RXg3ssqVHDr0M9vQ0 DUlYZT3g8JmJrKtPT+4UmYKLZMO91JXGDZDUDxQvZCGGTQqBkobqEXK5Ok2bsYem8zyC K8TgTZgd7fWP3sOLg3AASIrYsWQ2uR43a6JoGnczil3iq0h7awnz0oNTW4XKd0XqnA9v cXL8+s9PqoIESECyJPZ9uDfL3WvCe8+DYetj/GUiu+QS9dTOHZbGvqKubTncMXH/8TBw OMhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=xdHl/etckiQR9elD+uCN1KU5yBbkzeqp6P+9xsk6lvk=; b=HV/5Bd1IoCLFN781z8f8Cn2xckoHkk31KRs0O1uzgXDRTVne1t95aHfwfudq7i7srR 2MiFuFWrdUvsidb3FjryLSqE6sux8VTx9j8kwnEkMw808Gp3dL4RWDfzqvTUMpbcH10I uA2+lKIW0StKOULEMRSExp3uV6su9S0oGV6tayzrxUb57wDNPrerOOwR/+A6URmMtrRk CoiFWjjJjxz112BgkVV9O9IHRPY/F1ThqtaUp6AXGAx6RlW+cqumjHglJJuWU60fT44J 4PEpNPnWm6vVKpEdVr/D2442wMKOFaBoRkd57Ku7fsqdXQtRGvtX0gNjcyNKvUIrMSvG fSIw== X-Gm-Message-State: AJcUukeNcx7cAuzSXPjnZlQ769V99XKi3Dm32h/0npTUzfdPXPeJ8rXb imqXZ+QOWAIUBka57QXAzKdoYQ== X-Google-Smtp-Source: ALg8bN6tcVDKVkH4IjcYvyITg1tN27i4TWVBm3r9apLDsGdj+wHkEBTRGBYaOgy0nXitIJer1Ma0nQ== X-Received: by 2002:a37:5741:: with SMTP id l62mr46766841qkb.44.1546564552205; Thu, 03 Jan 2019 17:15:52 -0800 (PST) Received: from alvin.alvh.no-ip.org ([201.186.80.67]) by smtp.gmail.com with ESMTPSA id u45sm28872177qtk.33.2019.01.03.17.15.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 03 Jan 2019 17:15:51 -0800 (PST) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id EB13B517; Thu, 3 Jan 2019 22:15:49 -0300 (-03) Date: Thu, 3 Jan 2019 22:15:49 -0300 From: Alvaro Herrera To: Yuri Niyazov Cc: pgsql-admin@lists.postgresql.org Subject: Re: your mail Message-ID: <201901040115.2m6fmgg2yfav@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716-1013-2c1e88 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Jan-03, Yuri Niyazov wrote: > We are running Postgresql 9.3.8. We had something fairly surprising happen > here the other day: we started reaching the vacuum limit, with our logs > filling up with “WARNING: database "mydb" must be vacuumed within > 177009986 transactions” messages, hundreds of them per second, and we came > dangerously close to experiencing a DB shutdown. *However*, there were only > three things running that were writing to the database - a db-wide VACUUM > that we manually started, a per-table autovacuum that postgres itself > started, and a "write 1 row every 1-minute" cron job into a separate table > that we use to track replication delay. I suggest to consider an urgent upgrade to at least 9.3.11, but really all the way to the end of 9.3, and quickly afterwards plan an upgrade to the latest 9.4 in a short timeframe. 9.3.8 contains known bugs, which the first upgrade gets you out of; but 9.3 as a whole is out of support since a couple of months, so you'll be playing with fire until you're in 9.4. Do not postpone to upgrade to 9.3.latest while planning the upgrade to 9.4, though. I wonder if you fell prey to this weird behavior: https://postgr.es/m/CAMkU=1yE4YyCC00W_GcNoOZ4X2qxF7x5DUAR_kMt-Ta=YPyFPQ@mail.gmail.com -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services