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

Re: postgres crash on CURSORS

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: 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-04 20:15:11
Message-ID: 200004042015.QAA29607@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> 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.

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

In response to

pgsql-hackers by date

Next:From: Mike MascariDate: 2000-04-04 20:22:56
Subject: Re: Indexes growing continuously
Previous:From: Tom LaneDate: 2000-04-04 20:06:27
Subject: Re: postgres crash on CURSORS

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