Re: Detect supported SET parameters when pg_restore is run - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Detect supported SET parameters when pg_restore is run
Date
Msg-id 2739.1475010752@sss.pgh.pa.us
Whole thread Raw
In response to Re: Detect supported SET parameters when pg_restore is run  (Vitaly Burovoy <vitaly.burovoy@gmail.com>)
Responses Re: Detect supported SET parameters when pg_restore is run
Re: Detect supported SET parameters when pg_restore is run
List pgsql-hackers
Vitaly Burovoy <vitaly.burovoy@gmail.com> writes:
> On 9/27/16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> It does not seem that I'm "overwriting it long before the dump process
> is over"...

There's a lot that happens during RestoreArchive.  Even if none of it
inspects remoteVersion today, I do not think that's a safe assumption to
make going forward.  The easiest counterexample is that this very bit of
code you want to add does so.  I really do not want to get into a design
that says "remoteVersion means the source server version until we reach
RestoreArchive, and the target version afterwards".  That way madness
lies.  If we're going to try altering the emitted SQL based on target
version, let's first create a separation between those concepts; otherwise
I will bet that we add more bugs than we remove.

(The other thing I'd want here is a --target-version option so that
you could get the same output alterations in pg_dump or pg_restore to
text.  Otherwise it's nigh undebuggable, and certainly much harder
to test than it needs to be.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: to_date_valid()
Next
From: David Steele
Date:
Subject: Re: Fix checkpoint skip logic on idle systems by tracking LSN progress