Re: default_isolation_level='serializable' crashes on Windows

On 12.08.2012 17:39, Tom Lane wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)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.

> A larger point is that I think it's broken for any GUC assignment
> function to be calling something as transient as RecoveryInProgress to
> start with. We probably ought to re-think the logic, not just band-aid
> this by having it skip the check when shmem isn't initialized yet.
> I'm thinking that the check has to occur somewhere outside GUC.

Hmm, it seems like the logical place to complain if you do a manual "SET
transaction_isolation='serializable'". But I think we should only do the
check if we're not in a transaction. Setting the guc won't have any
effect outside a transaction anyway, because StartTransaction will
overwrite it from default_transaction_isolation as soon as you begin a
transaction.

While playing around, I bumped into another related bug, and after
googling around I found out that it was already reported by Robert Haas
earlier, but still not fixed:
http://archives.postgresql.org/message-id/CA%2BTgmoa0UM2W1YkjjneEgJctzxopC3G53ocYPaCyoEOWT3aKiA%40mail.gmail.com.
Kevin, the last message on that thread
(http://archives.postgresql.org/pgsql-hackers/2012-04/msg01394.php) says
you'll write a patch for that. Ping? Or would you like me to try that?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com