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;
> test=> DECLARE bigtable_cursor CURSOR FOR
test-> SELECT * FROM bigtable;
> 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))
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.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2000-04-04 20:15:11|
|Subject: Re: postgres crash on CURSORS|
|Previous:||From: Bruce Momjian||Date: 2000-04-04 20:04:50|
|Subject: Re: CURSOR after hitting end|