RE: About row locking ordering

From: "Ryo Yamaji (Fujitsu)" <yamaji(dot)ryo(at)fujitsu(dot)com>
To: 'Kirk Wolak' <wolakk(at)gmail(dot)com>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: RE: About row locking ordering
Date: 2022-12-07 03:03:27
Message-ID: TYAPR01MB607338C0C3A81AC8788094388A1A9@TYAPR01MB6073.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


Thank you for your comments. Sorry for the late reply.

From: Kirk Wolak Sent: Friday, November 25, 2022 6:12 PM
> My first question is why are you not using "WHERE CURRENT OF" cursor_name?

I thought that cursors are preferred for manipulating large numbers of rows.
So I did not consider using cursors in this test case because each process manipulates only one row.

However, assuming general usage, I thought it would be preferable to use a cursor, as you pointed out, because it might result in fewer table accesses.
I didn't have that knowledge.

> But effectively, you are locking the row and that is the row you want to update (the current row of the cursor).
> I wonder if that addresses the problem...

I tested it with a cursor, but there was still a problem..
I will attach the script used for the test, though it will be simple.

Attachment Content-Type Size
testset2.zip application/x-zip-compressed 1.2 KB

In response to

Browse pgsql-general by date

  From Date Subject
Next Message vignesh C 2022-12-07 11:22:19 Re: Support logical replication of DDLs
Previous Message Bruce Momjian 2022-12-07 02:32:03 Re: snapshot question