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

From Amit Kapila
Subject Re: default_isolation_level='serializable' crashes on Windows
Date
Msg-id 003f01cd792a$b359b340$1a0d19c0$@kapila@huawei.com
Whole thread Raw
In response to Re: default_isolation_level='serializable' crashes on Windows  (Amit Kapila <amit.kapila@huawei.com>)
List pgsql-hackers
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Amit Kapila
Sent: Monday, August 13, 2012 12:47 PM
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@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.linnakangas@enterprisedb.com>  writes:


>>> 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?

transaction_isolation is getting written to config_exec_params file as
function 
write_one_nondefault_variable() checks if conf source is not PGC_S_DEFAULT,
then it writes to file.
For transaction_isolation, the conf source is set to PGC_S_OVERRIDE in
function InitializeGUCOptions()
so this also gets written to config_exec_params file.
Should the parameter transaction_isolation be written to config_exec_params?


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




pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Proof of concept: auto updatable views
Next
From: Magnus Hagander
Date:
Subject: Re: Yet another failure mode in pg_upgrade