default_isolation_level='serializable' crashes on Windows

A customer reported that when you set 
default_isolation_level='serializable' in postgresql.conf on Windows, 
and try to start up the database, it crashes immediately. And sure 
enough, it does, on REL9_1_STABLE as well as on master.

Stack trace:

postgres!RecoveryInProgress+0x3a 
[c:\postgresql\src\backend\access\transam\xlog.c @ 7125]
postgres!check_XactIsoLevel+0x162 
[c:\postgresql\src\backend\commands\variable.c @ 617] postgres!call_string_check_hook+0x6d 
[c:\postgresql\src\backend\utils\misc\guc.c @ 8226]
postgres!set_config_option+0x13e5 
[c:\postgresql\src\backend\utils\misc\guc.c @ 5652] postgres!read_nondefault_variables+0x27f 
[c:\postgresql\src\backend\utils\misc\guc.c @ 7677]
postgres!SubPostmasterMain+0x227 
[c:\postgresql\src\backend\postmaster\postmaster.c @ 4101]
postgres!main+0x1e9 [c:\postgresql\src\backend\main\main.c @ 187]
postgres!__tmainCRTStartup+0x192 
[f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crtexe.c @ 586]
postgres!mainCRTStartup+0xe 
[f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crtexe.c @ 403]
kernel32!BaseThreadInitThunk+0xd
ntdll!RtlUserThreadStart+0x1d

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.

I'm not sure what the cleanest fix for this would be. It seems that we 
could should just trust the values the postmaster passes to us and 
accept them without checking RecoveryInProgress(), but there's no 
straightforward way to tell that within check_XactIsoLevel(). Another 
thought is that there's really no need to pass XactIsoLevel from 
postmaster to a backend anyway, because it's overwritten from 
default_transaction_isolation as soon as you begin a transaction.

There's also a call to RecoveryInProgress() in 
check_transaction_read_only() as well, but it seems to not have this 
problem. That's more by accident than by design, though.

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