RE: postgres crash on CURSORS

> -----Original Message-----
> From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
> Behalf Of Bruce Momjian
> 
> > 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.
>

Is it bad to check ABORTED after yyparse() in parser.c ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp