Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1etf3O-0008Jc-MV for pgsql-admin@arkaria.postgresql.org; Wed, 07 Mar 2018 19:48:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1etf3K-000724-W7 for pgsql-admin@arkaria.postgresql.org; Wed, 07 Mar 2018 19:48:42 +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.89) (envelope-from ) id 1etf3K-00071u-H4 for pgsql-admin@lists.postgresql.org; Wed, 07 Mar 2018 19:48:42 +0000 Received: from mail-qt0-x243.google.com ([2607:f8b0:400d:c0d::243]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1etf3H-0008J9-2F for pgsql-admin@postgresql.org; Wed, 07 Mar 2018 19:48:40 +0000 Received: by mail-qt0-x243.google.com with SMTP id y6so4084453qtm.7 for ; Wed, 07 Mar 2018 11:48:38 -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=9ilRgfvFYOtMN68Ic0uGzI3NsR65p4XwBQEPbZvfS88=; b=YHH2RtVqEV3FXd2HH4RMohZVfPyRhFXKBaxBm3cf2EMy0u1GQCo/SZIERjdN7r0zJI sP4ChVF0HfdeLpyQZCoFECR6bzKMKwpjPThCdIDqdx3X1TmK95IMlHzbmqHk3hMSO9VR eKOSQuw9ZQGTTsrar76KOUgu7tGw2PV7UfapJdptSB9uzrspEIcLdVq0/yf0IK/uQfql fz/ofvyMdsDhNeohM27Ov8fHaBWl/iEcdz1WYqWiNECUrfHgtGP6m0jOXSFbrTCsV/ar wNpZaLbpraz9gmnq7W1GtexEHjGpQ408YHs1IshQsjZITBswGVhmhUgVzjhXYA00Q2Eb hVfw== 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=9ilRgfvFYOtMN68Ic0uGzI3NsR65p4XwBQEPbZvfS88=; b=jDSuJ9Bu3ctEa/87xiCs6u/Gjt4qwWr5vybXrorHQxhqu/+LUFYT407gGaBwnynYdA pS1Hx73T90avkH1sKDSRa73sQfurfSG3wJmSYshfZ1l88BS6Q5Wa7xNY9o3l0bCTqssn sTnAQhPPIYCOlvhKjFeZVCKR3yn1R+XCGnjy70ErC2NImUz5WFl7jL6YZ+eSzBiKyHkl XbCB+Y8gKSAtCszXg+WvDDLhi7znqs+wBwK95RsRt5MPLboa2Wp095IWkTyEpo27n+m4 mdy7JcmF/ZXR3t05aCYEsIXIQFIGhwuM//Pbu8yo0QBRRJEkKESogOE1r+gUfel+mZp4 NG6Q== X-Gm-Message-State: AElRT7EC8eGMPXGqd4RW182Sp8jRQp6qrjdIOr8HQDRloPJuN6BNTov0 Uu0oJG8xouIybH96nC1B8WwkyQ== X-Google-Smtp-Source: AG47ELtPEiI+XbyTWjIeBlWeYqDhLh4Jr9ILqYO/7xJsn9JSiTDvOZpxQbFiszxmRQ1HZ3CmxfBJNQ== X-Received: by 10.200.2.11 with SMTP id k11mr34742611qtg.292.1520452118002; Wed, 07 Mar 2018 11:48:38 -0800 (PST) Received: from alvin.alvh.no-ip.org ([179.56.29.253]) by smtp.gmail.com with ESMTPSA id m66sm12235564qkl.43.2018.03.07.11.48.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 07 Mar 2018 11:48:20 -0800 (PST) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 7EE43880; Wed, 7 Mar 2018 16:48:11 -0300 (-03) Date: Wed, 7 Mar 2018 16:48:11 -0300 From: Alvaro Herrera To: bricklen Cc: Natalie Wenz , pgsql-admin Subject: Re: pg_upgrade and frozen xids Message-ID: <20180307194811.tloezvberxo33faw@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk bricklen wrote: > We recently upgraded about 1500 Postgres clusters from 9.3 to 10.1 and we > are seeing similar issues. Specifically: > * An autovacuum worker stuck vacuuming regular tables for days until they > are killed (I've seen "vacuuming indexes" phase), and they are showing 99% > CPU in top. pg_cancel|terminate_backend does not usually kill the process, > only a hard kill does. In the latter case, two (out of four) times it also > crashed Postgres. > * There have been about 10 examples of btree index corruption, across a > handful of databases, in different data centres. In two of the cases, it's > possible there were hardware issues as the hypervisor those two VM's were > running on crashed. I wonder if this may be related to changes in collation algorithm. If the indexes are all on text columns, I think you would be better served by reindexing them all instead of trying to treat this situation as a code bug. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services