Re: pg_dump/pg_restore vs default_transaction_read_only under PG 13.2

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump/pg_restore vs default_transaction_read_only under PG 13.2
Дата
Msg-id 1511776.1624211267@sss.pgh.pa.us
обсуждение исходный текст
Ответ на pg_dump/pg_restore vs default_transaction_read_only under PG 13.2  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
Ответы Re: pg_dump/pg_restore vs default_transaction_read_only under PG 13.2  (Vijaykumar Jain <vijaykumarjain.github@gmail.com>)
Re: pg_dump/pg_restore vs default_transaction_read_only under PG 13.2  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
Список pgsql-general
Karsten Hilbert <Karsten.Hilbert@gmx.net> writes:
> I am testing the pg_restore of a database with
> default_transaction_read_only=on.

Hm.  It's intentional that we reconnect after applying the database
properties, so that they are in effect during the restore.  It seems
likely that failing to do so could result in misbehaviors.

Hence, the only way to make this scenario work would be for the
restore script to explicitly override default_transaction_read_only.
That seems like a darn bad idea, really.  If pg_dump thinks it's
authorized to ignore that, why shouldn't every other application?

Also, doing so would result in ignoring default_transaction_read_only
no matter what the source of that was.  I think it's probably not
hard to construct scenarios where someone would really not be happy
about such behavior.

In short, I'm inclined to say "don't do that".  Maybe it'd be
a better idea to apply default_transaction_read_only to particular
roles (and not run pg_restore under such a role).

            regards, tom lane



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

Предыдущее
От: Karsten Hilbert
Дата:
Сообщение: Re: pg_dump/pg_restore vs default_transaction_read_only under PG 13.2
Следующее
От: Vijaykumar Jain
Дата:
Сообщение: Re: pg_dump/pg_restore vs default_transaction_read_only under PG 13.2