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:
http://www.postgresql.org/mailpref/pgsql-hackers
