From: | Nick Barnes <nickbarnes01(at)gmail(dot)com> |
---|---|
To: | Florian Pflug <fgp(at)phlo(dot)org> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Subject: | Re: Question about RI checks |
Date: | 2014-10-21 16:54:06 |
Message-ID: | CAG+WGGk5thyh-MQ7T3H4bUBz+tSQpR+kZ==ex0+cmAposKbFmA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thanks! I've been mulling this over for weeks; nice to know it wasn't just
staring me in the face...
So in conclusion, the lock avoids raising constraint violation errors in
> a few cases in READ COMMITTED mode. In REPEATABLE READ mode, it converts
> some
> constraint violation errors into serialization failures. Or at least that's
> how it looks to me.
>
Yeah, it had occurred to me that this is one place you might see some
benefit. But waiting around on a potentially irrelevant update, just in
case the RI violation resolves itself, didn't really sound like a net win.
Not to mention the possibility of a deadlock, if the other transaction
updates our PK or adds another reference to it.
Thanks again,
Nick Barnes
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-10-21 17:16:46 | Getting rid of "accept incoming network connections" prompts on OS X |
Previous Message | Kevin Grittner | 2014-10-21 16:19:55 | Re: Question about RI checks |