Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lBbmK-0001hj-AW for pgsql-pkg-debian@arkaria.postgresql.org; Mon, 15 Feb 2021 11:10:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lBbmJ-0006CF-5Z for pgsql-pkg-debian@arkaria.postgresql.org; Mon, 15 Feb 2021 11:10:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lBbmJ-0006A6-0Y for pgsql-pkg-debian@lists.postgresql.org; Mon, 15 Feb 2021 11:10:55 +0000 Received: from feynman.df7cb.de ([195.49.152.168]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lBbmC-0004vO-Ef for pgsql-pkg-debian@postgresql.org; Mon, 15 Feb 2021 11:10:54 +0000 Received: from msg.df7cb.de (unknown [IPv6:2a02:908:1478:7c00:65be:7834:a7af:3c7c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by feynman.df7cb.de (Postfix) with ESMTPSA id 4DfLxf6bpxz3DwS; Mon, 15 Feb 2021 12:10:46 +0100 (CET) Date: Mon, 15 Feb 2021 12:10:46 +0100 From: Christoph Berg To: Saif Hakim , Aaron Pavely Cc: pgsql-pkg-debian@postgresql.org Subject: Re: libpq 11.10 / 11.11 are not propertly released for bionic Message-ID: Mail-Followup-To: Christoph Berg , Saif Hakim , Aaron Pavely , pgsql-pkg-debian@postgresql.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Re: Saif Hakim > > that is indeed stale, thanks for spotting that. The problem is present > > in the other distributions as well. I have now manually updated > > bionic-pgdg, but I will leave the other untouched until I can figure > > Thanks!, I've confirmed that my repro no longer works and version 11 is > installed. In the meantime I found the issue: to speed up getting the different PG major versions out for the release, I had told reprepro not to "export" the Packages files except on the last version processed. Normally this is fine, since the last run would export all the files touched, but as the extra components are only touched by a single PG major version each, the last run had only exported the extra files for that PG version, leaving the other versions in the old state. I have now exported all the dists manually again and things will be back on track in a few minutes with the next mirror run. > > That said, you shouldn't worry about libpq5 11 - using the 13 version > > from the "main" repository component is the recommended way. > > For my own understanding, what are the ramifications of using the > non-"main" repository component / what are the differences? The non-main components contain the lib packages only, so you can't actually install postgresql-11 from there since that is contained in "main". If you want libpq5 only, you can of course go with "11" only (or "main 11"), but I have yet to hear from a case where libpq5 version 13 isn't just working as well. > Out of curiosity, if we were running libpq5-11 with Postgres 13, would we > see any issues or does postgres maintain backwards compatibility with these > libs as well? On the client side, you should be able to see much of a difference, the protocol is the same. Possibly there are some functions in libpq5 that are only available with 13, but dpkg's dependency tracking will tell you if a newer version is required. Re: Aaron Pavely > Actually, I received a few complaints the other day from developers for the > bionic-pgdg/9.6 component when 9.6.21 was pushed, so Saif's issue was not > an isolated incident. At the time, I saw that the 'Packages' file was > similarly last updated in November. Everything looks good now, though. Nod. > While I recommend to my teams use the 'main' component for libpq, there > continues to be fear among many that libpq versions mismatched from the > parent database cluster version may cause unexpected issues — even after I > point out that the database cluster itself is using the most recent release > of libpq from the 'main' component. Right. (But note that the PG server itself doesn't actually use libpq, it's only required for things like postgres_fdw and dblink.) Christoph