From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>, Lee McKeeman <lmckeeman(at)opushealthcare(dot)com> |
Subject: | Re: [BUGS] Status of issue 4593 |
Date: | 2009-01-12 14:03:09 |
Message-ID: | 87y6xglizm.fsf@oxford.xeocode.com |
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> writes:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> I can see two ways forward:
>
>> 1) We document bluntly that ORDER BY + FOR UPDATE can return unordered
>> results, or
>
>> 2) We prohibit ORDER BY + FOR UPDATE, like we do with a number of other
>> clauses. (There would be no loss of functionality, because you can run
>> the query a second time in the transaction with ORDER BY.)
>
> That code has been working like this for eight or ten years now and this
> is the first complaint, so taking away functionality on the grounds that
> someone might happen to update the ordering column doesn't seem like the
> answer to me.
Can we detect it at run-time? If a recheck happens can we somehow know which
columns could be problematic to find updated and check that they're unchanged?
I'm pretty sure the answer is no, but I figured I would throw it out there in
case it gives anyone an idea.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
From | Date | Subject | |
---|---|---|---|
Next Message | Rigo Nyfjeld | 2009-01-12 14:15:45 | BUG #4610: password |
Previous Message | Tom Lane | 2009-01-12 13:32:38 | Re: [BUGS] Status of issue 4593 |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-12 14:04:04 | Re: Recovery Test Framework |
Previous Message | Tom Lane | 2009-01-12 13:57:41 | Re: Assertion failure in plpgsql with INSTEAD OF rule |