Re: default_isolation_level='serializable' crashes on Windows

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