From: | Peter Schuller <peter(dot)schuller(at)infidyne(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Foreign keys causing conflicts leading to serialization failures |
Date: | 2008-04-01 17:48:51 |
Message-ID: | 20080401174850.GA42840@hyperion.scode.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hello,
Using PostgreSQL 8.2, I have "atable" one of whose columns reference a
column in "othertable". I see serialization failures as a result of
*inserts* to atable in the context of:
'"SELECT 1 FROM ONLY othertable x WHERE "otherid" = $1 FOR SHARE OF
x" ' in 'INSERT INTO atable (otherid, col2, col3) VALUES (.., ..,
..)'
My interpretation is that the acquisition of a lock on the row in
question is due to the enforcement of the foreign key constraint, and
that, combined with the fact that this locking is performed on a
per-row level, this creates a conflict with any concurrent transaction
updating that row in othertable, regardless of whether 'otherid' is
touched.
First off, is this correct?
If yes:
To me, it would be advantegous if "bogus" conflicts were not generated
like this. Although I realize that serializable transactions are
subject to retries, one still tends to design transactions
specifically to avoid generating conflicts. It is useful to know that
a particular transaction is guaranteed to not generate serialization
failures. And if that is not possible, than at least minimizing the
risk is useful. Normally, an INSERT is conflict-free and it would be
nice to keep it that way.
Unfortunately, the introduction of enforced referential integrity has
this negative side effect.
If my interpretation above is correct; is the use of row-level locking
due to:
(1) it being mandated by a standard?
(2) "cell"-level beinginefficient?
(3) no one having implemented "cell"-level locking?
(4) there being a problem with having a DELETE correctly
conflict with a "cell"-level lock?
(*) something else?
In short, I am wondering whether this behavior is intended or a
side-efffect of implementation details.
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <peter(dot)schuller(at)infidyne(dot)com>'
Key retrieval: Send an E-Mail to getpgpkey(at)scode(dot)org
E-Mail: peter(dot)schuller(at)infidyne(dot)com Web: http://www.scode.org
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-04-01 18:03:18 | Re: Getting weird pg_tblspc error, has anyone seen this before? |
Previous Message | Ivan Sergio Borgonovo | 2008-04-01 17:34:10 | still on techniques to cache table slices was: optimiser STABLE vs. temp table |