From: Tom Lane <tgl@sss.pgh.pa.us>
To: dzja112@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18531: err when using 'current of' with incremental COMMIT
In-reply-to: <18531-c6dddd33b8555fd2@postgresql.org>
References: <18531-c6dddd33b8555fd2@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Tue, 09 Jul 2024 11:00:29 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3167931.1721059660.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 15 Jul 2024 12:07:40 -0400
Message-ID: <3167932.1721059660@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3167932.1721059660%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> That combine 'current of' and 'commit' at one loop is bad idea?

Yeah, that's not going to work.  The first COMMIT auto-holds the
cursor [1], and after that there is not an active cursor query for
the WHERE CURRENT OF to refer to.  Even if that data were somehow
retained, the COMMIT would have dropped the tuple locks taken by
the cursor query, so that the semantics would be a lot squishier
than you'd want.

The discussion at [1] fails to mention that there are any such
gotchas implicit in the auto-hold behavior, so I added a little
bit of text [2].

			regards, tom lane

[1] https://www.postgresql.org/docs/current/plpgsql-transactions.html
[2] https://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dcommitdiff;h=
=3Da0899c0a97d19b0c330ff885af4b78b3e7efb100