Alvaro Herrera wrote:
> On 2019-Jun-13, Alvaro Herrera wrote:
>
>> On 2019-Jun-13, Oleksii Kliukin wrote:
>>
>>> Makes sense. For the symmetry I have included those that perform lock
>>> upgrades in one session and those that doesn’t, while the other sessions
>>> acquire locks, do updates or
On 2019-Jun-13, Alvaro Herrera wrote:
> On 2019-Jun-13, Oleksii Kliukin wrote:
>
> > Makes sense. For the symmetry I have included those that perform lock
> > upgrades in one session and those that doesn’t, while the other sessions
> > acquire locks, do updates or deletes. For those that don’t
On 2019-Jun-13, Oleksii Kliukin wrote:
> Makes sense. For the symmetry I have included those that perform lock
> upgrades in one session and those that doesn’t, while the other sessions
> acquire locks, do updates or deletes. For those that don’t upgrade locks the
> test checks that the locks are
On Wed, Jun 12, 2019 at 12:47 PM Alvaro Herrera
wrote:
> Please don't simplify the table name to just "t" -- the reason I used
> another name is that we want these tests to be able to run concurrently
> at some point; ref.
> https://postgr.es/m/20180124231006.z7spaz5gkzbdvob5@alvherre.pgsql
Not
Hello,
Alvaro Herrera wrote:
> On 2019-Jun-12, Oleksii Kliukin wrote:
>
>> Thank you! I can make it even simpler; s1 just acquires for share lock, s3
>> gets for update one and s2 takes for share lock first, and then tries to
>> acquire for update one; once s1 finishes, s3 deadlocks.
>
>
On 2019-Jun-12, Oleksii Kliukin wrote:
> Thank you! I can make it even simpler; s1 just acquires for share lock, s3
> gets for update one and s2 takes for share lock first, and then tries to
> acquire for update one; once s1 finishes, s3 deadlocks.
Cool. I think it would be worthwhile to
Oleksii Kliukin wrote:
> Hi,
>
> Alvaro Herrera wrote:
>
>> On 2019-May-22, Oleksii Kliukin wrote:
>>
>>> X1: select id from job where name = 'a' for key share;
>>> Y: select id from job where name = 'a' for update; -- starts waiting for X1
>>> X2: select id from job where name = 'a' for key
Hello
On 2019-May-22, Oleksii Kliukin wrote:
> I have recently observed a deadlock on one of our production servers related
> to locking only a single row in a job table. There were two functions involved
> in the deadlock, the first one acquires a “for key share” lock on the row that
>
Hello,
I have recently observed a deadlock on one of our production servers related
to locking only a single row in a job table. There were two functions involved
in the deadlock, the first one acquires a “for key share” lock on the row that
represents the job it works on and subsequently
