Re: Determine if FOR UPDATE or FOR SHARE was used?

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Determine if FOR UPDATE or FOR SHARE was used?
Date: 2019-03-21 03:31:30
Message-ID: 5C930592.3080206@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03/18/19 00:45, Tom Lane wrote:
> I think it would help to take two steps back and ask why you want
> to know this, and what exactly is it that you want to know, anyhow.
> What does it matter if there's FOR SHARE in the query? Does it

I was looking at an old design decision in PL/Java, which implements
java.sql.ResultSet by grabbing a pile of tuples at a time from
SPI_cursor_fetch, and then letting the ResultSet API iterate through
those, until the next pile needs to be fetched.

It seemed like the kind of optimization probably very important in a
client/server connection over RFC 2549, but I'm not sure how important
it is for code running right in the backend.

Maybe it does save a few cycles, but I don't want to be watching when
somebody tries to do UPDATE or DELETE WHERE CURRENT OF.

It occurred to me that positioned update/delete could be made to work
either by simply having the Java ResultSet row fetch operations correspond
directly to SPI fetches, or by continuing to SPI-fetch multiple rows at
a time, but repositioning with SPI_cursor_move as the Java ResultSet
pointer moves through them. (Is one of those techniques common in other
PLs?)

But it also occurred to me that there might be a practical way to
examine the query to see it's one that could be used for positioned
update or delete at all, and avoid any special treatment if it isn't.

Regards,
-Chap

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-03-21 03:39:38 Re: MacPorts support for "extra" tests
Previous Message Tom Lane 2019-03-21 03:22:53 Re: PostgreSQL pollutes the file system