From: | Steven Winfield <Steven(dot)Winfield(at)cantabcapital(dot)com> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | RE: Row locks, SKIP LOCKED, and transactions |
Date: | 2019-12-18 10:42:49 |
Message-ID: | E9FA92C2921F31408041863B74EE4C2001E7664F89@CCPMAILDAG03.cantab.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>> * 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.html#XACT-READ-COMMITTED
>
>"UPDATE, DELETE, SELECT FOR UPDATE, and SELECT FOR SHARE commands ..."
>
>If I read correctly, transactions can see the effects of other
>transactions that commit during their lifetime.
Thanks. I had a look at those docs when I first encountered the issue (if it can be called that), which prompted me to try repeatable read and serializable isolation levels, but to no avail. I couldn't find anything specifically mentioning the visibility of row locks at different isolation levels.
From | Date | Subject | |
---|---|---|---|
Next Message | Steven Winfield | 2019-12-18 11:33:07 | RE: Row locks, SKIP LOCKED, and transactions |
Previous Message | James (王旭) | 2019-12-18 09:53:26 | How to prevent POSTGRES killing linux system from accepting too much inserts? |