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