| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 18:06:44 |
| Message-ID: | 496CD834.1080603@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
Kevin,
> So, wouldn't it be better, if it's actually feasible to detect the
> problem situation, to make this another situation where SELECT FOR
> UPDATE can cause serialization failures? That would allow
> applications to count on getting the rows in the requested order if
> the query completes successfully. If existing documentation doesn't
> already cover the possibility of serialization failures when using FOR
> UPDATE, it should. If we need to document something around the issue
> of this thread, that seems like the place to do it.
That's not how SELECT FOR UPDATE works. SFU is pessimistic manual
locking, which is supposed to *wait* for the rows to be exclusively
available. The deadlock timeout you encountered is the correct
behaviour, not "serialization failure", which is what happens at commit
time when the engine realizes that concurrent transactions are not
serializably recreateable.
--Josh
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2009-01-13 18:18:40 | Re: [BUGS] Status of issue 4593 |
| Previous Message | Kevin Grittner | 2009-01-13 17:29:02 | Re: [BUGS] Status of issue 4593 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2009-01-13 18:18:40 | Re: [BUGS] Status of issue 4593 |
| Previous Message | Tom Lane | 2009-01-13 17:33:30 | Re: New patch for Column-level privileges |