Re: Write skew observed under serializable isolation - Mailing list pgsql-hackers

From Zsolt Parragi
Subject Re: Write skew observed under serializable isolation
Date
Msg-id CAN4CZFMs1W11eBpvo5bJsGaXoEBKkdcgZiBW9VzWTmGkD3zW5w@mail.gmail.com
Whole thread
In response to Re: Write skew observed under serializable isolation  (Aleksander Alekseev <aleksander@tigerdata.com>)
Responses Re: Write skew observed under serializable isolation
List pgsql-hackers
> The proper fix is to acquire SIREAD on the relation.

That's a way to fix it, but I am not sure that it is the proper way to
do it because it locks way more than needed.

One issue is that now this takes a whole relation lock for UPDATE ...
WHERE CURRENT OF, which can cause false-positive abort of cursor
loops. I think this part is fixable with an extended condition.

Also after I looked into this a bit more today, cb5b28613d5 in 2020
introduced SO_TYPE_TIDSCAN exactly to prevent full relation locks.
Maybe the reasoning of that commit was wrong, and we indeed need whole
relation locks there, but it doesn't seem like a trivial decision to
me.



pgsql-hackers by date:

Previous
From: Lukas Fittl
Date:
Subject: Re: PostgreSQL 19 Beta 4 release announcement draft
Next
From: Masahiko Sawada
Date:
Subject: Re: [PATCH] Use bounded GIN pending-list cleanup in parallel autovacuum