Tom Lane wrote: > Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: >> On all versions starting from 8.0 where subtransactions were introduced, >> this causes an assertion failure: > > Ugh :-( > > This ties into the more general issue that it's not clear what effect a > subtransaction rollback should have on a cursor. You could argue that > ideally the cursor should revert to its pre-savepoint state. We didn't > implement that in 8.0 because it seemed too hard, but this bug shows > that not rolling back the cursor isn't exactly easy either.
Yeah, the current behavior is debatable. But it's quite sane, useful and well-defined as it is, so I don't feel any urge to change it. > Not sure what to do. The only fix that seems bulletproof at the moment > is to declare that any cursor that's been touched at all in a > subtransaction is marked "broken" if the subtransaction rolls back. > That might be too great a loss of functionality. It would block off > the controversial aspects of behavior though ... Hmm, I think we should track temporary files using resource owners. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
