From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Lee McKeeman" <lmckeeman(at)opushealthcare(dot)com>, "PG Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [BUGS] Status of issue 4593 |
Date: | 2009-01-13 17:29:02 |
Message-ID: | 496C7AFE.EE98.0025.0@wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Huh? Deadlocks were not the issue here. What you asked for was a
> failure if someone else had updated the rows you're selecting for
> update.
Logically, these are both forms of serialization failure when doing
SELECT FOR UPDATE in READ COMMITTED mode. One currently deadlocks,
generating an error that requires a retry. The other quietly fails to
return the requested results. I'm suggesting that it would be better
to generate an error with an indication of the serialization failure.
You said that people use READ COMMITTED to avoid such errors. I'm
pointing out that they can currently get serialization failure errors
in READ COMMITTED if they choose to SELECT FOR UPDATE.
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2009-01-13 18:06:44 | Re: [BUGS] Status of issue 4593 |
Previous Message | Tom Lane | 2009-01-13 17:16:28 | Re: [BUGS] Status of issue 4593 |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2009-01-13 17:31:55 | Re: Latest version of Hot Standby patch |
Previous Message | Stephen Frost | 2009-01-13 17:23:41 | Re: New patch for Column-level privileges |