Re: postgres crash on CURSORS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: postgres crash on CURSORS
Date
Msg-id 17011.954915052@sss.pgh.pa.us
Whole thread Raw
In response to RE: postgres crash on CURSORS  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses RE: postgres crash on CURSORS  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List pgsql-hackers
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> The check for abort state has to happen in the appropriate paths of
>> execution, not in the parser.  Not all statements should reject on
>> abort state.

> Are there any statements which should be executable on abort state
> except ROLLBACK/COMMIT ?

I dunno ... but offhand, I see no really good reason for checking this
in the parser rather than the way it's done now.  Presumably only
utility statements would be candidates for exemption from abort checks,
so checking in the switch statement in ProcessUtility makes sense to
me --- that way the knowledge of the semantics of a given utility
statement is localized.

> The following is a sample patch for parser.c.

The specific patch you propose is definitely inferior to the currently-
committed code, because it does not deal properly with COMMIT/ROLLBACK
appearing within a list of queries.  If we are in abort state and
the submitted query string is
SELECT foo ; ROLLBACK ; SELECT bar

it seems to me that the correct response is to reject the first select
and process the second.  The currently committed code does so, but
your patch would fail.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: RE: postgres crash on CURSORS
Next
From: "Hiroshi Inoue"
Date:
Subject: RE: postgres crash on CURSORS