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