| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| 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-12 19:21:08 |
| Message-ID: | 3962.1231788068@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> If that's what you want then you run the transaction in serializable
>> mode.
> If you run this at SERIALIZABLE transaction isolation level, would
> PostgreSQL currently roll something back before returning rows in an
> order different than that specified by the ORDER BY clause?
Yes, it would roll back as soon as it found that any of the selected
rows had been concurrently modified. The behavior where you get back
the updated version of the row is specific to READ COMMITTED mode.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Hayen | 2009-01-12 21:49:53 | BUG #4612: lc_numeric setting ignored |
| Previous Message | Jeff Davis | 2009-01-12 19:11:53 | Re: [BUGS] Status of issue 4593 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-01-12 19:31:17 | Re: Recovery Test Framework |
| Previous Message | Dave Page | 2009-01-12 19:20:36 | Re: Recovery Test Framework |