Re: Unexpected *ABORT STATE*

Jan Wieck wrote:
>
> Joseph Shraibman wrote:
> > Mike Finn wrote:
> > >
> >
> > > problem but I was wondering why this occurs, and if it is on the todo list to
> > > fix.
> >
> > It occurs because once an error happens all the changes that have been
> > made may not mean anything, so the transaction must be rolled back.
> > Maybe there is something that could be set to interactive programs like
> > psql can disable this? If not there should be, becuase I too have been
> > anoyed with a long interactive session having to be restarted because of
> > a typo.
>
> There is absolutely nothing that could be set to "disable" it
> and continue the transaction. This is because the system has
> no idea how to distinguish between a syntax typo and a
> duplicate key error for example. Both are simply and ERROR.
> Now for a typo it'd not be critical, but for a dupkey - er -
> the heap typle is there, not all indexes might have been
> processed and for sure the referential integrity constraint
> triggers and other stuff haven't been run. That's an
> inconsistent DB state, isn't it? Are you sure you want that?

Then that command would fail and not alter the state of the db as seen
within the transaction block. The previous alterations withing the
transaction block would still be there, waiting to be commited.

>

--
Joseph Shraibman
jks(at)selectacast(dot)net
Increase signal to noise ratio. http://www.targabot.com