Re: about error handling mechanism

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: fanng yuan <fanngyuan(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: about error handling mechanism
Date: 2010-12-17 14:26:54
Message-ID: 4D0B732E.5030005@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17.12.2010 11:18, fanng yuan wrote:
> Hi!
> I was looking into the postgres error handling mechanism, and the
> documentation states that the present mechanism is primitive.
>
> I quote "whenever the parser, planner/optimizer or executor decide that a
> statement cannot be processed any longer,
> the whole transaction gets aborted and the system jumps back into the main
> loop to get the next command from the client application."

That quote is from the 7.4 manual. You should look at something more recent.

> Also, it states " it is possible that the database server is in an
> inconsistent state at this point so returning to the upper executor or
> issuing
> more commands might corrupt the whole database"
>
> Since postgres aborts the transaction compeletely, why would it be ever
> left in an inconsistant state in such an event?

What it tries to say is that the system might be in an inconsistent
state, which is the reason the transaction has to be aborted. The abort
cleans it up, so you're not left in an inconsistent state.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2010-12-17 14:45:56 Re: clang and LLVM
Previous Message Alvaro Herrera 2010-12-17 13:36:06 Re: bug in SignalSomeChildren