From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Detect supported SET parameters when pg_restore is run |
Date: | 2016-09-27 14:39:06 |
Message-ID: | CA+TgmoaevWjS6eJENxTFvXrJpvANtDp_dHRBRFjpS8oMvK6Urg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 26, 2016 at 9:56 PM, Vitaly Burovoy
<vitaly(dot)burovoy(at)gmail(dot)com> wrote:
> At work we use several major versions of PostgreSQL, and developers
> use non-local clusters for developing and debugging.
> We do dump/restore schemas/data via custom/dir formats and we have to
> keep several client versions for 9.2, 9.4 and 9.5 versions on local
> workstations because after pg_restore95 connects to 9.2, it fails when
> it sets run-time parameters via SET:
>
> vitaly(at)work 01:21:26 ~ $ pg_restore95 --host DEV_HOST_9_2 -d DBNAME
> --data-only -e -1 -Fc arhcivefile
> Password:
> pg_restore95: [archiver (db)] Error while INITIALIZING:
> pg_restore95: [archiver (db)] could not execute query: ERROR:
> unrecognized configuration parameter "lock_timeout"
> Command was: SET lock_timeout = 0;
I think our policy is that a newer pg_dump needs to work with an older
version of the database, but I don't think we make any similar
guarantee for other tools, such as pg_restore. It's an interesting
question whether we should try a little harder to do that, but I
suspect it might require more changes than what you've got in this
patch....
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2016-09-27 14:42:49 | Re: |
Previous Message | Robert Haas | 2016-09-27 14:31:53 | Re: |