Re: Segmentation fault with core dump

I wrote:
> (Wanders away wondering just how much the regression tests exercise
> holdable cursors.)

And the answer is they're not testing this code path at all, because if
you do
DECLARE c CURSOR WITH HOLD FOR ...
FETCH ALL FROM c;
then the second query executes with a portal (and resource owner)
created to execute the FETCH command, not directly on the held portal.

After a little bit of thought I'm not sure it's even possible to
reproduce this problem with libpq, because it doesn't expose any way to
issue a bare protocol Execute command against a pre-existing portal.
(I had thought psqlOBC went through libpq, but maybe it's playing some
games here.)

Anyway, I'm thinking the appropriate fix might be like this

- CurrentResourceOwner = portal->resowner;
+ if (portal->resowner)
+ CurrentResourceOwner = portal->resowner;

in several places in pquery.c; that is, keep using
TopTransactionResourceOwner if the portal doesn't have its own.

A more general but probably much more invasive solution would be to fake
up an intermediate portal when pulling data from a held portal, to
more closely approximate the explicit-FETCH case.

regards, tom lane