Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: > On 12.08.2012 17:39, Tom Lane wrote: >> A larger point is that I think it's broken for any GUC assignment >> function to be calling something as transient as RecoveryInProgress to >> start with.
> Hmm, it seems like the logical place to complain if you do a manual "SET > transaction_isolation='serializable'". But I think we should only do the > check if we're not in a transaction. You mean "if we *are* in a transaction"? Possibly that would work. The concerns I've got about running this type of test in a GUC hook are (1) what if you're not in a transaction or (2) what if you aren't in a process that has access to shared memory; the early-startup-in- EXEC_BACKEND case loses on both counts. But I think we can test our local in-transaction state without touching shared memory, and then go from there. > While playing around, I bumped into another related bug, and after > googling around I found out that it was already reported by Robert Haas > earlier, but still not fixed: > http://archives.postgresql.org/message-id/CA%2BTgmoa0UM2W1YkjjneEgJctzxopC3G53ocYPaCyoEOWT3aKiA%40mail.gmail.com That sounds like a different bug, although perhaps with the same theme of overreliance on what a GUC hook can do. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
