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 1gRk7e-00044H-IY for pgsql-committers@arkaria.postgresql.org; Tue, 27 Nov 2018 20:38:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gRk7d-00085g-CU for pgsql-committers@arkaria.postgresql.org; Tue, 27 Nov 2018 20:38:17 +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 1gRk7b-00085P-Ha for pgsql-committers@lists.postgresql.org; Tue, 27 Nov 2018 20:38:17 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gRk7X-0007Ef-Qv for pgsql-committers@lists.postgresql.org; Tue, 27 Nov 2018 20:38:14 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 61D32BF8; Tue, 27 Nov 2018 15:38:10 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 27 Nov 2018 15:38:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=hmLcLlw55NFo2ElsEQZ/0yIEXS0 ytIKi2ycLUqWSLEQ=; b=V6eWPo29HIV49e9ecQuPSpxRJ88AY1m4BZD4OCUeSDx FB/Y8aIpIulUyjWJkmFUV+oBGdokGJ24kUgYpqTzVQZWjMZuDRo8n89mgSGcsfwz bEFwETbSTSUeocvthVnrHxrbP00TEW7RC158+bkbAtQ+4UOfVc6kgA9nE0DMwu9f pVFw1xh8HK2z2GYatKEoEMWmsAa8LJYJPIK9r0//LkC3Xc5MoazOEsjUS9GVMEd4 KxgHgl/nQ4s3Lbnu2uTCLqjaMMnijhExwWG4OGdLKW7jT4PQzabNSzmQdSBeI3Tc iodjimGS45BX7pZbv6vNQdz62Pv01kEp4X0spKRWPYQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=hmLcLl w55NFo2ElsEQZ/0yIEXS0ytIKi2ycLUqWSLEQ=; b=xlDnhFoi9LZNvnA8Ee93KU jcAoMhgnd2VHmjWTOigkKnaAAW/tSIG+XJTsSDvpDgwVQ3LUfUiKkASFOIz4bc/7 cegWAPQNantZ98flGXT2AFLfIWV2Ttz22/FHkl1sgXR3Rly14DlqTDYpHaXDRFMl 3EDk78sifxBNi32+TPKsJyD5UxhEIGaeOq2Yb62heDk6x1fyEXycE7Gbr3KC3ZHN 3fO4lc2l2Nz6n8ZHFUtCZuDzJ1/NQe7SrGTAO/DMHjScLoDsdQ3earWTQKFQh4Gs eVvj4cQELkt++2qM4uPfjKH9AJw9PlKh6TwzzppkeWhyqw9q7aYZ+NKAFa+Q6kvg == X-ME-Sender: X-ME-Proxy: Received: from intern.anarazel.de (c-98-210-140-171.hsd1.ca.comcast.net [98.210.140.171]) by mail.messagingengine.com (Postfix) with ESMTPA id 3268610301; Tue, 27 Nov 2018 15:38:09 -0500 (EST) Date: Tue, 27 Nov 2018 12:38:06 -0800 From: Andres Freund To: Tom Lane Cc: Andrew Dunstan , pgsql-committers@lists.postgresql.org Subject: Re: pgsql: Update pg_upgrade test for reg* to include regrole and regnamesp Message-ID: <20181127203806.behekoj55rnwuuvg@alap3.anarazel.de> References: <8863.1543297423@sss.pgh.pa.us> <20181127063226.mpyijg3jwrmmm3rr@alap3.anarazel.de> <6f5edd28-e55f-7399-d89c-d2d1ed2d1e51@2ndQuadrant.com> <2735.1543333649@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2735.1543333649@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 2018-11-27 10:47:29 -0500, Tom Lane wrote: > Andrew Dunstan writes: > > In any case, I think we will probably need to bite the bullet and have > > pg_dump render LOs in OID order. > > +1. Looking at the relevant code: > > /* > * Currently, we re-fetch all BLOB OIDs using a cursor. Consider scanning > * the already-in-memory dumpable objects instead... > */ > if (fout->remoteVersion >= 90000) > blobQry = "DECLARE bloboid CURSOR FOR SELECT oid FROM pg_largeobject_metadata"; > else > blobQry = "DECLARE bloboid CURSOR FOR SELECT DISTINCT loid FROM pg_largeobject"; Done. Thanks for chiming in. Andrew, the <= 9.2 failure https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2018-11-27%2018%3A18%3A21 seems to be related to nabstime etc not being available anymore. We've not backpatched Author: Tom Lane Branch: REL_11_STABLE Release: REL_11_0 [184951a48] 2018-10-12 19:33:56 -0400 Branch: REL_10_STABLE Release: REL_10_6 [9320263ae] 2018-10-12 19:33:56 -0400 Branch: REL9_6_STABLE Release: REL9_6_11 [2ad422ce1] 2018-10-12 19:33:56 -0400 Branch: REL9_5_STABLE Release: REL9_5_15 [43cc4e49e] 2018-10-12 19:33:56 -0400 Branch: REL9_4_STABLE Release: REL9_4_20 [7b88c1ddd] 2018-10-12 19:33:57 -0400 Branch: REL9_3_STABLE Release: REL9_3_25 [fb583c80d] 2018-10-12 19:33:57 -0400 Remove abstime, reltime, tinterval tables from old regression databases. that far. I've locally verified that upgrade works after SELECT format('ALTER TABLE %s DROP COLUMN %s;', attrelid::regclass, attname) FROM pg_attribute WHERE attrelid > 16384 AND atttypid IN ('abstime'::regtype, 'reltime'::regtype, 'tinterval'::regtype) \gexec or something in that vein. Greetings, Andres Freund