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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
