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.

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

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

Reply via email to