Heikki Linnakangas <heikki.linnakangas@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
