Re: postgres crash on CURSORS

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I have found I can crash the backend with the following queries:
>     test=> BEGIN WORK;
>     BEGIN
>     test=> DECLARE bigtable_cursor CURSOR FOR
test-> SELECT * FROM bigtable;
>     SELECT
>     test=> FETCH 3 prior FROM bigtable_cursor;
>     ERROR:  parser: parse error at or near "prior"
>     test=> FETCH prior FROM bigtable_cursor;
>     pqReadData() -- backend closed the channel unexpectedly.
>             This probably means the backend terminated abnormally
>             before or while processing the request.
>     The connection to the server was lost. Attempting reset: Succeeded.

Problem appears to be due to trying to bull ahead with processing after
the current transaction has been aborted by an error.  The immediate
cause is these lines in postgres.c:
           /*            * We have to set query SnapShot in the case of FETCH or COPY TO.            */           if
(nodeTag(querytree->utilityStmt)== T_FetchStmt ||               (nodeTag(querytree->utilityStmt) == T_CopyStmt &&
        ((CopyStmt *)(querytree->utilityStmt))->direction != FROM))               SetQuerySnapshot();
 

which are executed without having bothered to check for aborted state.
I think this code should be removed from postgres.c, and the
SetQuerySnapshot call instead made from the Fetch and Copy arms of the
switch statement in ProcessUtility() (utility.c), after doing
CHECK_IF_ABORTED in each case.
        regards, tom lane