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
