| 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: | Whole Thread | Raw Message | 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 |