Re: v12 and pg_restore -f- - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: v12 and pg_restore -f-
Date
Msg-id 20191105143445.GL6962@tamriel.snowman.net
Whole thread Raw
In response to Re: v12 and pg_restore -f-  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
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.
>
> 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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: v12 and pg_restore -f-
Next
From: Stephen Frost
Date:
Subject: Re: v12 and pg_restore -f-