From: | Jeff Amiel <jamiel(at)istreamimaging(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andre Maasikas <andre(dot)maasikas(at)abs(dot)ee>, John Sidney-Woollett <johnsw(at)wardbrook(dot)com>, pgsql-general(at)postgresql(dot)org, "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
Subject: | Re: using database for queuing operations? |
Date: | 2004-09-23 15:37:06 |
Message-ID: | 4152EDA2.5010507@istreamimaging.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"The search condition of the command (the WHERE clause) is re-evaluated
to see if the updated version of the row still matches the search
condition. If so, the second updater proceeds with its operation,
starting from the updated version of the row."
Hey....that's neat. All this time, I've done an unncessary extra select
to see if the value has changed because of competing processes trying to
work on same row....
Once again...kudos to lists like this one and of course, RTFM.
Jeff
Tom Lane wrote:
>Jeff Amiel <jamiel(at)istreamimaging(dot)com> writes:
>
>
>>>"the docs say that in case of locked rows the where clause is reevaluated: "
>>>
>>>
>
>
>
>>Is this true?
>>Which docs are you refering to (I could find no mention in the postgres
>>docs).....
>>
>>
>
>Second paragraph in
>http://developer.postgresql.org/docs/postgres/transaction-iso.html#XACT-READ-COMMITTED
>
> regards, tom lane
>
>
>
>
--
Jeff Amiel
Systems/Development Manager
iStream Imaging, an iTeam Company
jamiel(at)iStreamImaging(dot)com
(262) 796-0925 x1011
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Murphy | 2004-09-23 15:56:09 | using COPY table FROM STDIN within script run as psql -f file.sql |
Previous Message | Kevin Murphy | 2004-09-23 15:33:47 | mailing list archive search form broken? |