Re: postgres crash on CURSORS

> 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