Re: persistent portals/cursors (between transactions)
От | Tom Lane |
---|---|
Тема | Re: persistent portals/cursors (between transactions) |
Дата | |
Msg-id | 3685.1011808451@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | persistent portals/cursors (between transactions) (Florian Wunderlich <fwunderlich@devbrain.de>) |
Ответы |
Re: persistent portals/cursors (between transactions)
Re: persistent portals/cursors (between transactions) |
Список | 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 по дате отправления: