default_isolation_level='serializable' crashes on Windows - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject default_isolation_level='serializable' crashes on Windows
Date
Msg-id 50277FAD.7040901@enterprisedb.com
Whole thread Raw
Responses Re: default_isolation_level='serializable' crashes on Windows
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: error handling in logging hooks
Next
From: Tom Lane
Date:
Subject: Re: default_isolation_level='serializable' crashes on Windows