From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Florian Wunderlich" <fwunderlich(at)devbrain(dot)de> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: persistent portals/cursors (between transactions) |
Date: | 2002-01-23 21:14:32 |
Message-ID: | EKEJJICOHDIEMGPNIFIJEEDKGJAA.Inoue@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> -----Original Message-----
> From: Tom Lane
>
> Florian Wunderlich <fwunderlich(at)devbrain(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Wunderlich | 2002-01-23 21:20:17 | Re: persistent portals/cursors (between transactions) |
Previous Message | Tom Lane | 2002-01-23 20:47:28 | Re: persistent portals/cursors (between transactions) |