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.

Here is the backtrace.  Comments?

---------------------------------------------------------------------------


#0  0x281d2d65 in kill ()
#1  0x2821ea5d in abort ()
#2  0x8146548 in ExcAbort (excP=0x8199294, detail=0, data=0x0, 
    message=0x81812ad "!(MyProc->xmin != 0)") at excabort.c:27
#3  0x8146497 in ExcUnCaught (excP=0x8199294, detail=0, data=0x0, 
    message=0x81812ad "!(MyProc->xmin != 0)") at exc.c:170
#4  0x81464ef in ExcRaise (excP=0x8199294, detail=0, data=0x0, 
    message=0x81812ad "!(MyProc->xmin != 0)") at exc.c:187
#5  0x8145b3a in ExceptionalCondition (
    conditionName=0x81812ad "!(MyProc->xmin != 0)", exceptionP=0x8199294, 
    detail=0x0, fileName=0x81811a3 "sinval.c", lineNumber=362) at assert.c:73
#6  0x8103730 in GetSnapshotData (serializable=0 '\000') at sinval.c:362
#7  0x81501d7 in SetQuerySnapshot () at tqual.c:611
#8  0x810c329 in pg_exec_query_dest (
    query_string=0x81cd398 "FETCH prior FROM bigtable_cursor;\n", dest=Debug, 
    aclOverride=0) at postgres.c:677
#9  0x810c244 in pg_exec_query (
    query_string=0x81cd398 "FETCH prior FROM bigtable_cursor;\n")
    at postgres.c:607
#10 0x810d43d in PostgresMain (argc=4, argv=0x8047534, real_argc=4, 
    real_argv=0x8047534) at postgres.c:1642
#11 0x80c07fc in main (argc=4, argv=0x8047534) at main.c:103
#12 0x8062a9c in __start ()

-- 
  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, Pennsylvania 19026

Tue, 4 Apr 2000 15:12:53 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
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

Tue, 04 Apr 2000 16:06:27 -0400
Tom Lane <tgl@sss.pgh.pa.us>
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, Pennsylvania 19026

Tue, 4 Apr 2000 16:15:11 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: postgres crash on CURSORS