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

Re: postgres crash on CURSORS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
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 06:10:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"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

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


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

In response to


pgsql-hackers by date

Next:From: Hiroshi InoueDate: 2000-04-05 08:05:19
Subject: RE: postgres crash on CURSORS
Previous:From: Hiroshi InoueDate: 2000-04-05 06:00:19
Subject: RE: postgres crash on CURSORS

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