> -----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
