Skip site navigation (1) Skip section navigation (2)

RE: postgres crash on CURSORS

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: postgres crash on CURSORS
Date: 2000-04-05 04:02:06
Message-ID: 001601bf9eb3$b5407c20$2801007e@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
> -----Original Message-----
> From: pgsql-hackers-owner(at)hub(dot)org [mailto:pgsql-hackers-owner(at)hub(dot)org]On
> Behalf Of Bruce Momjian
> 
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)tpf(dot)co(dot)jp

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-04-05 04:04:07
Subject: Re: postgres crash on CURSORS
Previous:From: Bruce MomjianDate: 2000-04-05 03:45:25
Subject: Re: int8.c compile problem on UnixWare 7.x

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group