[GENERAL] PG96 pg_restore connecting to PG95 causes ERROR: unrecognizedconfiguration parameter "idle_in_transaction_session_timeout"

Поиск
Список
Период
Сортировка
От Justin Pryzby
Тема [GENERAL] PG96 pg_restore connecting to PG95 causes ERROR: unrecognizedconfiguration parameter "idle_in_transaction_session_timeout"
Дата
Msg-id 20170506002253.GJ8016@telsasoft.com
обсуждение исходный текст
Ответы Re: [GENERAL] PG96 pg_restore connecting to PG95 causes ERROR: unrecognized configuration parameter "idle_in_transaction_session_timeout"  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
When doing a dump+restore upgrade, it's commonly recommended to use the later
version of pg_restore:

https://www.postgresql.org/docs/current/static/upgrading.html
"It is recommended that you use the pg_dump and pg_dumpall programs from the
newer version of PostgreSQL, to take advantage of enhancements that might have
been made in these programs. Current releases of the dump programs can read
data from any server version back to 7.0."

In the immediate case, I was loading data from PG95 dumps into PG95 server (not
an upgrade), using P96 pg_restore, and getting:

    ERROR:  unrecognized configuration parameter "idle_in_transaction_session_timeout"

I can't see anybody has raised that issue before.  Should pg_restore check the
remote server version and avoid sending commands not expected to be understood?

(Yes, I know and use pg_upgrade, however I'm currenting migrating a DB between
servers and this procedure will allow doing so with ~30min
downtime...pg_upgrade to 9.6 will be done afterwards, which is why PG96
pg_upgrade is installed).

Thanks,
Justin


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

Предыдущее
От: Mathieu Fenniak
Дата:
Сообщение: [GENERAL] Logical decoding CPU-bound w/ large number of tables
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] Logical decoding CPU-bound w/ large number of tables