Thread: ...
unsubscribe psql-admin -- Best regards, Alexey mailto:beholder@roaddep.ru
select * from temptable where tempcolumn != 'blah'||'blah';
or
select * from temptable where tempcolumn <> 'blah'||'blah';
I could be wrong, but there may be an bug in the order of precedence.
If you try the above query, postgres will return:
ERROR: array value must start with "{" or dimension information
If you group the expressions as;
select * from temptable where tempcolumn != ('blah'||'blah');
or
select * from temptable where tempcolumn <> ('blah'||'blah');
it works like a charm.
Just curious if there is a reason for this order of operation. Thanks
Kris
______________________________
Kris Kiger
Software Developer
Digonex Technologies, Inc.
317.638.4174 Fax
CONFIDENTIALITY NOTICE: The information in this transmission is private, confidential, may be legally privileged, is
propertyof the sender and is intended solely for the use of the addressee. If you are not the addressee, you should
notread, disclose, distribute, copy, use or rely upon the information contained in this transmission. If you have
receivedthis transmission in error please delete or destroy it and notify DIGONEX TECHNOLOGIES, INC. immediately at
(317)638-4154.
Quick question. I lock a table, call it table X, and then issue two updates on that table. The two updates are left waiting. I then unlock the table. The two updates go through. My question is, is there a predictable way to determine which query will be executed first? Thanks in advance Kris
On Mon, 2005-05-09 at 12:21 -0500, Kris Kiger wrote: > Quick question. I lock a table, call it table X, and then issue two > updates on that table. The two updates are left waiting. I then unlock > the table. The two updates go through. My question is, is there a > predictable way to determine which query will be executed first? Thanks > in advance The lock queue is served in FIFO sequence. It is predictable, but if you don't know which order they were submitted in it might be hard to determine what that predictable order is, if they were submitted almost at the same time. ...but you shouldn't use locking as a queuing mechanism. Best Regards, Simon Riggs
Simon Riggs <simon@2ndquadrant.com> writes:
> On Mon, 2005-05-09 at 12:21 -0500, Kris Kiger wrote:
>> Quick question. I lock a table, call it table X, and then issue two
>> updates on that table. The two updates are left waiting. I then unlock
>> the table. The two updates go through. My question is, is there a
>> predictable way to determine which query will be executed first?
> The lock queue is served in FIFO sequence.
... usually. We will promote later arrivals in front of older ones if
the alternative would be a deadlock (eg, the later one already holds
some lock that would block the earlier one).
regards, tom lane
On Mon, 2005-05-09 at 15:18 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > On Mon, 2005-05-09 at 12:21 -0500, Kris Kiger wrote: > >> Quick question. I lock a table, call it table X, and then issue two > >> updates on that table. The two updates are left waiting. I then unlock > >> the table. The two updates go through. My question is, is there a > >> predictable way to determine which query will be executed first? > > > The lock queue is served in FIFO sequence. > > ... usually. We will promote later arrivals in front of older ones if > the alternative would be a deadlock (eg, the later one already holds > some lock that would block the earlier one). Thats part of deadlock detection? I had thought we just blew one away... Thanks, Best Regards, Simon Riggs
Simon Riggs <simon@2ndquadrant.com> writes:
> On Mon, 2005-05-09 at 15:18 -0400, Tom Lane wrote:
>> ... usually. We will promote later arrivals in front of older ones if
>> the alternative would be a deadlock (eg, the later one already holds
>> some lock that would block the earlier one).
> Thats part of deadlock detection? I had thought we just blew one away...
Only after deciding that there's no way to rearrange the lock queues to
eliminate the deadlock.
regards, tom lane