Re: Detect supported SET parameters when pg_restore is run

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Detect supported SET parameters when pg_restore is run
Дата
Msg-id CA+TgmoaevWjS6eJENxTFvXrJpvANtDp_dHRBRFjpS8oMvK6Urg@mail.gmail.com
обсуждение исходный текст
Ответ на Detect supported SET parameters when pg_restore is run  (Vitaly Burovoy <vitaly.burovoy@gmail.com>)
Ответы Re: Detect supported SET parameters when pg_restore is run  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Sep 26, 2016 at 9:56 PM, Vitaly Burovoy
<vitaly.burovoy@gmail.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@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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re:
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: