Date: Tue, 5 Nov 2019 09:34:45 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	"imai.yoshikazu@fujitsu.com" <imai.yoshikazu@fujitsu.com>,
	Euler Taveira <euler@timbira.com.br>,
	Andrew Gierth <andrew@tao11.riddles.org.uk>,
	Justin Pryzby <pryzby@telsasoft.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: v12 and pg_restore -f-
Message-ID: <20191105143445.GL6962@tamriel.snowman.net>
References: <20191104145336.GA23924@alvherre.pgsql>
 <5e124b1d-bd8f-0659-1088-4952464223bc@2ndquadrant.com>
 <20191105141132.GK6962@tamriel.snowman.net>
 <1d8a8c5f-410f-46b9-e5e8-4d5884ff0093@2ndquadrant.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="mAFcLccE4vZfyAY5"
Content-Disposition: inline
In-Reply-To: <1d8a8c5f-410f-46b9-e5e8-4d5884ff0093@2ndquadrant.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--mAFcLccE4vZfyAY5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> On 2019-11-05 15:11, Stephen Frost wrote:
> >We don't guarantee this kind of compatibility between major versions.
>=20
> We do generally ensure compatibility of client side tools across major
> versions.  I don't recall a case where we broke compatibility in a
> comparable way without a generous transition period.

No, we don't.

The compatibility of client side tools across major versions that we
provide is that newer versions will work with older databases- eg:
pg_dump will work back many many years, as will psql, and that's very
clear as we have specific code in those client side tools to work with
older database versions.  However, if you're migrating to the newer
version of the tool or the database, you need to test with that new
version and should expect to have to make some changes.

We routinely make changes, like the removal of recovery.conf, changing
the name of pg_xlog to pg_wal, renaming pg_xlogdump to pg_waldump and
pg_resetxlog to pg_resetwal, the other xlog -> wal name changes, that
will break scripts that people have written (not to mention serious
applications like pgAdmin, barman, pgbackrest, postgres_exporter,
pg_partman, et al), and certainly we do that without any more lead time
than "this is what's in the new release."  The XLOG -> WAL changes were
even committed quite late in the cycle, February it looks like, with the
location -> lsn changes happening in May.

I also can't recall off-hand a specific case where we said "this
behavior is going to change in release current_release+2, so be
prepared", mostly because the point is well made consistently that: a)
we don't want to guarantee any such change will actually happen in some
kind of timeline like that, meaning people can't actually plan for it,
and b) people will either make the change proactively because they track
what we're doing closely, or will wait until they actually go to try and
use the new version, in which case if it works then they won't bother
changing and if it doesn't then they'll put in the effort to make the
change, there's no real middle ground there.

Thanks,

Stephen

--mAFcLccE4vZfyAY5
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJdwYiFAAoJEO1sijiDR2RVq3wP/2U++ub+nE/8pVgmct5TV9d7
HrWMICXCGEKT+YHGeC/cg1sUxVphfafjg5PxfSCtLFRClc8gcTrYxaMAiw0OLOL9
0cuxv2PlbR/8845bJg+466oTJZuybN2zl5mmJ/waHOTyo3Ryz0DRT5xbQ88ysvbI
A4yauOwk8UD5P00RvdMqqozR9psr0FaM3XfsmmshTx4ku3omEMq28rXTdeBy208m
zoDTVYNaC1CQoFKdI84dB/x05cY523JqNcfvOgKCfPR8RV0XTzdgPTGnLiORYvwF
OhvRz1dRGLrDCMgxd3f79+FaOI6jSkR0H2DGnx+cQYuG7Gl3+K9QTZNiXKa1pz/z
30pGJMytdAipggYiwBORmsl5ya84zoTmNHz3s3QpfImAV6kuV9QxbajvJuZyhVkw
si3lV+HOnmNYP0PvUDvkf3oJbI/TIxq4IvFy8idAl5/wx86DgHW9rwS0LmIuBzFw
R63E0DyLj8Iul2eBGMpfYxZ2ePMjPs1ttYERvNnffOYETjIkmSsnjh5kyxKBo+8N
45h0V9O6LTlr6vAgNBNxFunqm78mxQc+i/qZmAtIy5pBJNFvRtk7TnxsdYzfFNSp
6HkUnEEBigVT+F7CcC+sD35psSc2QOWIZDDPUeMUCHJvN0iqdjWmtr4gmrTawwzJ
XegABn0YoypeDxzy8vnz
=K4m4
-----END PGP SIGNATURE-----

--mAFcLccE4vZfyAY5--