> That may be because there is no guarantee of the ordering of your returned
> records.
That makes sense - I just didn't think of it. Doh!
> Maybe you need to re-initialise your variables before executing the
> select?
I'm not sure what variables I could re-initialise here as the select
statemen
On 10/12/2003 09:10 John Sidney-Woollett wrote:
[snip]
Actually from my tests, the simple code below *sometimes* blocks on the
locked row, and sometimes skips the locked row, and returns the next
unlocked row.
That may be because there is no guarantee of the ordering of your returned
records.
[s
> Unlikely as PostgreSQL doesn't support read uncommitted...
You're right - Postgres only offers two levels "PostgreSQL offers the Read
Committed and Serializable isolation levels."
> I think you need to play with a couple of psql sessions to sort this out.
> I think you might have a race conditi
On 09/12/2003 11:47 John Sidney-Woollett wrote:
Hi
I have a function called from a java app (via jdbc) which identifies
images awaiting processing. This is determined by checking the
WPImageStateID field on the WPImageHeader record (1=awaiting, 2=being
processed, 3=complete).
The (jdbc) connection
Hi
I have a function called from a java app (via jdbc) which identifies
images awaiting processing. This is determined by checking the
WPImageStateID field on the WPImageHeader record (1=awaiting, 2=being
processed, 3=complete).
The (jdbc) connection to the database is a standard one so I suspect
