Re: Detect supported SET parameters when pg_restore is run

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Detect supported SET parameters when pg_restore is run
Date: 2016-09-27 19:01:53
Message-ID: 29169.1475002913@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com> writes:
> On 9/27/16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The general policy has always been that pg_dump output is only expected to
>> restore without errors into a server that's the same or newer version as
>> pg_dump (regardless of the server version being dumped from).

> Why can't I use it if pg_dump92/pg_restore92 have the same behavior as
> pg_dump96/pg_restore96 except the SET block?

That's a pretty large "if", and not one I'm prepared to commit to.
Before you assert that it's true, you might want to reflect on the
size of the diff between 9.2 and 9.6 pg_dump (hint: it's over 20K
lines in -u format).

>> Either that, or the patch is overwriting pg_dump's idea of what the
>> source server version is at the start of the output phase, which is
>> likely to break all kinds of stuff when dumping from an older server.)

> I agree, that's why I left current behavior as is for the plain text output.

I'm not exactly convinced that you did. There's only one copy of
Archive->remoteVersion, and you're overwriting it long before the
dump process is over. That'd break anything that consulted it to
find the source server's version after RestoreArchive starts.

It might not be a bad thing to clearly distinguish source server version
from (expected?) target server version, but pg_dump doesn't do that
currently, and making it do so is probably not entirely trivial.
I think your patch confuses that distinction further, which
is not going to be helpful in the long run.

I could get behind a patch that split remoteVersion into sourceVersion
and targetVersion and made sure that all the existing references to
remoteVersion were updated to the correct one of those. After that
we could do something like what you have here in a less shaky fashion.
As Robert noted, there'd probably still be a long way to go before it'd
really work to use a newer pg_dump with an older target version, but at
least we'd not be building on quicksand.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jesper Pedersen 2016-09-27 19:06:14 Re: Hash Indexes
Previous Message Heikki Linnakangas 2016-09-27 18:58:06 Re: PL/Python adding support for multi-dimensional arrays