From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Heikki Linnakangas Sent: Monday, August 13, 2012 12:14 PM On 12.08.2012 17:39, Tom Lane wrote: > Heikki Linnakangas<heikki.linnakan...@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. Here What I am able to trace is that function read_nondefault_variables(), reads all variables from config_exec_params which contains both default_transaction_isolation and transaction_isolation. 1. it first reads default_transaction_isolation and sets value of DefaultXactIsoLevel to 'serializable'. 2. As for parameter default_transaction_isolation, there is no check function it passes. 3. After that when variable transaction_isolation is processed, function check_XactIsoLevel() sets XactIsoLevel to XACT_SERIALIZABLE which causes crash. Actually function read_nondefault_variables(), should only process non default values (default_transaction_isolation) not transaction_isolation, but currently it processes both? With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
