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

RE: postgres crash on CURSORS

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$ (view raw, whole thread or download thread mbox)
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;
=# 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

> > 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
> 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.


Hiroshi Inoue

In response to


pgsql-hackers by date

Next:From: Karel ZakDate: 2000-04-05 11:33:56
Subject: Re: caching query results
Previous:From: Tom LaneDate: 2000-04-05 06:10:52
Subject: Re: postgres crash on CURSORS

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