Re: persistent portals/cursors (between transactions) - Mailing list pgsql-general

From Hiroshi Inoue
Subject Re: persistent portals/cursors (between transactions)
Date
Msg-id EKEJJICOHDIEMGPNIFIJEEDKGJAA.Inoue@tpf.co.jp
Whole thread Raw
In response to Re: persistent portals/cursors (between transactions)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
> -----Original Message-----
> From: Tom Lane
>
> Florian Wunderlich <fwunderlich@devbrain.de> writes:
> > But there is no check in CreatePortal or SPI_cursor_open, as far as I've
> > seen, but as SPI doesn't allow transaction control statements I don't
> > know if SPI_connect probably begins a transaction implicitly.
>
> Any sort of SPI operation is implicitly within a transaction, since it
> can (by assumption) only be called from a function, which is being
> called within a query, which is explicitly or implicitly within a
> transaction.  So I think the lack of check there is okay.

This isn't necessarily true in other dbms's.

>
> > I'm wondering now why portals have to be dropped at the end of a
> > transaction.
>

At the end of a transaction PG system releases many resources
automatically. It isn't unclear to me what kind of resources should
be kept for persistent cursors between transactions and how to
keep them between transactions and finally release them cleanly.
As for locking Tom already implemented cross transaction locking.
But for example buffer pin/locks there isn't. It doesn't seem easy to
solve such items safely and cleanly. Of cource it isn't preferable to
introduce new bugs or needless complexity.
This is my long TODO item but unfortunately I have no clear idea
to achieve it.

regards,
Hiroshi Inoue


pgsql-general by date:

Previous
From: Florian Wunderlich
Date:
Subject: Re: persistent portals/cursors (between transactions)
Next
From: Andrew Snow
Date:
Subject: Re: Canadian website mirror]