Re: default_isolation_level='serializable' crashes on Windows

On 12.08.2012 17:39, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>  writes:
>> The problem is that when a postmaster subprocess is launched, it calls
>> read_nondefault_variables() very early, before shmem initialization, to
>> read the non-default config options from the file that postmaster wrote.
>> When check_XactIsoLevel() calls RecoveryInProgress(), it crashes,
>> because XLogCtl is NULL.
>
> Hm, how did the same code fail to crash in the postmaster itself, when
> the postmaster read the setting from postgresql.conf?

It's not the check function for default_transaction_isolation that 
crashes, but the one for transaction_isolation.

I'm not exactly sure how transaction_isolation gets set to a non-default 
value, though. The default for transaction_isolation is 'default', so 
it's understandable that the underlying XactIsoLevel variable gets set 
to XACT_SERIALIZABLE, but AFAICS the code to read/write the GUCs from/to 
file only cares about the string value of the guc, not the integer value 
of the underlying global variable.

> 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.  We probably ought to re-think the logic, not just band-aid
> this by having it skip the check when shmem isn't initialized yet.
> I'm thinking that the check has to occur somewhere outside GUC.

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. Setting the guc won't have any 
effect outside a transaction anyway, because StartTransaction will 
overwrite it from default_transaction_isolation as soon as you begin a 
transaction.

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. 
Kevin, the last message on that thread 
(http://archives.postgresql.org/pgsql-hackers/2012-04/msg01394.php) says 
you'll write a patch for that. Ping? Or would you like me to try that?

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com