Re: v12 and pg_restore -f-

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "imai(dot)yoshikazu(at)fujitsu(dot)com" <imai(dot)yoshikazu(at)fujitsu(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: v12 and pg_restore -f-
Date: 2019-11-05 14:34:45
Message-ID: 20191105143445.GL6962@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Greetings,

* Peter Eisentraut (peter(dot)eisentraut(at)2ndquadrant(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Stephen Frost 2019-11-05 14:38:12 Re: v12 and pg_restore -f-
Previous Message Tom Lane 2019-11-05 14:28:29 Re: v12 and pg_restore -f-

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2019-11-05 14:38:12 Re: v12 and pg_restore -f-
Previous Message Tom Lane 2019-11-05 14:28:29 Re: v12 and pg_restore -f-