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.

Yes, I saw this code and got totally confused of how to fix it.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026