| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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 09:18:57 |
| Message-ID: | 496C5C81.9020300@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
Tom Lane wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> A re-sort after locking doesn't really make things all nice and
>>> intuitive either.
>
>> Would it make any sense to roll back and generate a
>> SERIALIZATION_FAILURE?
>
> If that's what you want then you run the transaction in serializable
> mode. The point of doing it in READ COMMITTED mode is that you don't
> want such a failure.
Well, you can get deadlocks in read committed mode, so it is not like
this mode is totally free of concurrency related failure possibilities.
Both serialization errors and deadlocks assume a write operation though.
But could we detect this case at all? That is, when we are re-reading
the updated tuple, do we remember that we did some sorting earlier?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2009-01-13 09:22:04 | Re: [BUGS] Status of issue 4593 |
| Previous Message | Bruce Momjian | 2009-01-13 03:48:12 | Re: BUG #4612: lc_numeric setting ignored |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2009-01-13 09:22:04 | Re: [BUGS] Status of issue 4593 |
| Previous Message | Simon Riggs | 2009-01-13 09:17:24 | Re: Recovery Test Framework |