> (Or you could use serializable mode, but that feels like using a hammer to
> swat a fly.)
Do you mean the serializable transaction isolation level? Because that doesn't
work either. Here (finally) is a tiny repro case. You'll need 2 psql sessions
(S1, S2):
S1: CREATE TABLE t (id integer):
S1
Steven Winfield writes:
>> There are various ways you could deal with this, but I'd probably go for a
>> simple scheme where you only have to consult a single row to know if you
>> can claim it. You could still put the results into a separate table, but
>> use job.state to find work, and set it t
> Huh. SERIALIZABLE shouldn't allow two transactions to see no result row
> for a given ID and then insert a result row for that ID. One of those
> transactions should have to roll back, because otherwise it'd be
> incompatible with both serial orderings of the two transactions.
Sorry for the mi
>> * I observe this even if I crank up the transaction isolation level to
>> repeatable read and serializable.
>>
>>
>> I'm wondering if row locks are not obeying the same transactional semantics
>> as row data,
>Gotta believe it is this:
>
>https://www.postgresql.org/docs/11/transaction-iso
On Wed, Dec 18, 2019 at 5:12 AM Steven Winfield
wrote:
> * I observe this even if I crank up the transaction isolation level to
> repeatable read and serializable.
Huh. SERIALIZABLE shouldn't allow two transactions to see no result
row for a given ID and then insert a result row for that ID. O
On 12/17/19 8:12 AM, Steven Winfield wrote:
Hi all,
I'm seeing some unexpected behaviour with SELECT ... FOR UPDATE SKIP LOCKED,
and having finding it tricky to boil it down to a simple repro case as there's
almost certainly a race condition somewhere (more later). So I thought I would
ask if
