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]

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to