Re: postgresql-common: use latest version of pg_dump/restore

I added dump/restore to this list locally while updating a backup script
to use -Z zstd, but it seems like this would make sense to do widely,
since pg-dump/restore support a long history of versions, beyond the 5
release/years of versions nominally supported.

/usr/share/postgresql-common/pg_wrapper

# if we have no version yet, use the latest version. If we were called
# as psql, pg_archivecleanup, or pg_isready, always use latest version
if (not $version or $cmdname =~ /^(psql|pg_archivecleanup|pg_isready|pg_dump|pg_restore)$/) {

--
Justin

Re: Justin Pryzby
> I added dump/restore to this list locally while updating a backup script

Hmm, I thought that would void the ability to restore to the same old
version?

source server version <= pg_restore <= pg_dump <= target server

Christoph

On Sun, Apr 30, 2023 at 09:57:19PM +0200, Christoph Berg wrote:
> Re: Justin Pryzby
> > I added dump/restore to this list locally while updating a backup script
>
> Hmm, I thought that would void the ability to restore to the same old
> version?
>
> source server version <= pg_restore <= pg_dump <= target server

Maybe I'm misundertanding your diagram - did you mean this ?

> source server version <= pg_dump <= pg_restore <= target server

I think you're considering the issue where pg_dump support is dropped
for very old versions - that'd be something that's like ~10 years old.
For example if someone has a pg9.1 server, and then installs pg15
clients, which dropped support for v9.1.

Wouldn't that be handled here for pg_dump, the same as for psql ?

if ($version and $version < 9.2) { # psql 15 only supports PG 9.2+

--
Justin

Re: Justin Pryzby
> Maybe I'm misundertanding your diagram - did you mean this ?
>
> > source server version <= pg_dump <= pg_restore <= target server

Sorry, yes of course.

> I think you're considering the issue where pg_dump support is dropped
> for very old versions - that'd be something that's like ~10 years old.
> For example if someone has a pg9.1 server, and then installs pg15
> clients, which dropped support for v9.1.

If you use pg_dump X on an older version Y, it will still emit all the
SET commands that are applicable for version X:

-- Dumped from database version 9.3.25
-- Dumped by pg_dump version 16devel (Debian 16~~devel-1.pgdg+~20230428.1656.g81eaaf6)

SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SELECT pg_catalog.set_config('search_path', '', false);
SET check_function_bodies = false;
SET xmloption = content;
SET client_min_messages = warning;
SET row_security = off;

If you then try to feed that back to version Y, it will raise errors.

$ pg_dump -s | psql
SET
Zeit: 0,229 ms
SET
Zeit: 0,111 ms
FEHLER: 42704: unbekannter Konfigurationsparameter »idle_in_transaction_session_timeout«
ORT: set_config_option, guc.c:5229

Christoph