Foreign keys causing conflicts leading to serialization failures

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

Responses

Browse pgsql-general by date

  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