From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: postgres crash on CURSORS |
Date: | 2000-04-05 08:05:19 |
Message-ID: | 001a01bf9ed5$af50e440$2801007e@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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.
>
Current abort check seems too late.
For example,is the following behavior preferable ?
=# begin;
BEGIN
=# aaa;
ERROR: parser: parse error at or near "aaa"
=# select * from aaaa;
ERROR: Relation 'aaaa' does not exist
?? existence check ?? Why ??
reindex=# select * from t; -- t is a existent table
NOTICE: (transaction aborted): queries ignored until END
*ABORT STATE*
> > 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.
>
It seems pg_parse_and_plan() returns NIL plan_list and NIL
querytree_list in this case.
Regards.
Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Karel Zak | 2000-04-05 11:33:56 | Re: caching query results |
Previous Message | Tom Lane | 2000-04-05 06:10:52 | Re: postgres crash on CURSORS |