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

From Tom Lane
Subject Re: persistent portals/cursors (between transactions)
Date
Msg-id 3685.1011808451@sss.pgh.pa.us
Whole thread Raw
In response to persistent portals/cursors (between transactions)  (Florian Wunderlich <fwunderlich@devbrain.de>)
Responses Re: persistent portals/cursors (between transactions)  (Jan Wieck <janwieck@yahoo.com>)
Re: persistent portals/cursors (between transactions)  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List pgsql-general
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.

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

Because the table-level locks guaranteeing the existence and schema
stability of the referenced tables will go away when the transaction
ends.  Against that, there's not much point in sweating the small stuff
like whether we could drop and reacquire buffer pins ...

            regards, tom lane

pgsql-general by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Permissions on non-owned database
Next
From: Tom Lane
Date:
Subject: Re: postgresql 7.2b5 and vserver: statistics sockets