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 1h5z5v-00058T-CI for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Mar 2019 20:42:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h5z5s-0004Ce-On for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Mar 2019 20:42:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h5z5s-0004CX-Bp for pgsql-hackers@lists.postgresql.org; Mon, 18 Mar 2019 20:42:48 +0000 Received: from mail-qk1-x742.google.com ([2607:f8b0:4864:20::742]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h5z5l-0007Nu-2w for pgsql-hackers@postgresql.org; Mon, 18 Mar 2019 20:42:47 +0000 Received: by mail-qk1-x742.google.com with SMTP id w20so2322293qka.7 for ; Mon, 18 Mar 2019 13:42:40 -0700 (PDT) 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=Eldtt6HAPHKQkGmZXMsvcpMWssivj7EoSUkRXufDwHc=; b=UYPqjBs48/dIzteNZSgIpbIHp7MI6gXDluOKpwP/syu243NzrQW4NNStA9SBRdmldO 97aG0iQzMGiG4bW6sgJqZ3zBtXJJQFMJSuPU7Vz8FXJ24C99CAaaGfZVsdu7/IF7Pa8S dZt2B8eli4o0vdTXoeh51HdIXeN5yRzGwC2L//zheJK6nWjYzUMDupdJ2BOC7UZuiIRh DI1+DNlK1k3u1h5laeZ94Fen1IyqMY9Z0tBQYgmjoYnDAS6qgBw2AhrE6TT9yKVeV2d8 YFNuM3AnQZ5xaBR5/+TZVJ4US/lBViaBqA9ddAWjkThW+HD/U5aloU9CALRnGCauCTg7 kumA== 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=Eldtt6HAPHKQkGmZXMsvcpMWssivj7EoSUkRXufDwHc=; b=W7GAzoGOTpaKnP7SpEZQ8PJHWEq7H9VjpcaErz9WIYpSZBEoY2S1l+4aXVgM1d5EDc C+NYDa4Be76X7rvy018Jg9XGi8pPelKCcsRIi6m89qiAvJaTQZYUYnVnyrj4aJ7TkiXd d0nTL/1/4QFdOY5CeLRlq+YwJwnvW68mLCOcIO+rAG4/1pGt0o8ix209um/yH8+EJNO8 oAAYPYR11qelvx/LEWDryW8w4XOczM9ESW6lScFogGOzVbJZg4dPe5GpJu4INlqsrx9O yl5YKwQfRJ78hcjhb9Yqj7njklyRATqojbRml1yJCOV6UvN9YMfnfkbure1lFunhbLD1 pZhA== X-Gm-Message-State: APjAAAViXn46Po3lc41z1zl2jA8QWTfl/REHT34KtuHycwieMKVh8lpU 74WSQCjQ9kz5XUlq3fAqE0mwnw== X-Google-Smtp-Source: APXvYqyx1OiK97LTJKbugXfjkmVdirf+gOFECDuTMCrvycdQIhKbthqzRIKcc2jjTjQ4ItnlG/pgGw== X-Received: by 2002:a37:e315:: with SMTP id y21mr5684673qki.233.1552941758417; Mon, 18 Mar 2019 13:42:38 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id v52sm2012965qth.4.2019.03.18.13.42.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 18 Mar 2019 13:42:37 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 2BE31121DCB; Mon, 18 Mar 2019 17:42:35 -0300 (-03) Date: Mon, 18 Mar 2019 17:42:35 -0300 From: Alvaro Herrera To: Jesper Pedersen Cc: Amit Langote , Pg Hackers Subject: Re: partitioned tables referenced by FKs Message-ID: <20190318204235.GA30360@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --liOOAslEiF7prFVr Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hi Jesper On 2019-Mar-01, Jesper Pedersen wrote: > I'm getting a failure in the pg_upgrade test: > > -- > +-- Name: pk5 pk5_pkey; Type: CONSTRAINT; Schema: regress_fk; Owner: > jpedersen > +-- > + > +ALTER TABLE ONLY regress_fk.pk5 > + ADD CONSTRAINT pk5_pkey PRIMARY KEY (a); > + > + > +-- > > when running check-world. So I tested this case just now (after fixing a couple of bugs) and see a slightly different problem now: those excess lines are actually just that pg_dump chose to print the constraints in different order, as there are identical lines with "-" in the diff I get. The databases actually *are* identical as far as I can tell. I haven't yet figured out how to fix this; of course, the easiest solution is to just drop the regress_fk schema at the end of the foreign_key.sql regression test, but I would prefer a different solution. I'm going to post the new version of the patch separately. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diff --- /pgsql/build/part5/src/bin/pg_upgrade/tmp_check/dump1.sql 2019-03-18 17:28:00.201071102 -0300 +++ /pgsql/build/part5/src/bin/pg_upgrade/tmp_check/dump2.sql 2019-03-18 17:28:16.915627217 -0300 @@ -367111,6 +367111,14 @@ -- +-- Name: pk5 pk5_pkey; Type: CONSTRAINT; Schema: regress_fk; Owner: alvherre +-- + +ALTER TABLE ONLY regress_fk.pk5 + ADD CONSTRAINT pk5_pkey PRIMARY KEY (a); + + +-- -- Name: pk51 pk51_pkey; Type: CONSTRAINT; Schema: regress_fk; Owner: alvherre -- @@ -367127,14 +367135,6 @@ -- --- Name: pk5 pk5_pkey; Type: CONSTRAINT; Schema: regress_fk; Owner: alvherre --- - -ALTER TABLE ONLY regress_fk.pk5 - ADD CONSTRAINT pk5_pkey PRIMARY KEY (a); - - --- -- Name: at_partitioned_a_idx; Type: INDEX; Schema: public; Owner: alvherre -- --liOOAslEiF7prFVr--