Search Postgresql Archives

Re: pg_dump/pg_restore vs default_transaction_read_only under PG 13.2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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

is the below usecase relevant to this setup

i have db example which i want to migrate from one version to another.
to do that i disable writes on the db by setting the tx flag, so that i can be sure it is still serving reads, but no additional data is written.
i can take a pg_dump, the db is still serving the reads.
now when i do a restore on a higher verison, this fails, (ofcourse i can edit the dump and remove the setup), 

but is this above usecase logical for doing it.  




--
Thanks,
Vijay
Mumbai, India

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux