Re: pg_dump/pg_restore vs default_transaction_read_only under PG 13.2

>
> 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