AW: Now PostgreSQL recovers from errors within trns

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'hstenger(at)ieee(dot)org'" <hstenger(at)ieee(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: AW: Now PostgreSQL recovers from errors within trns
Date: 2000-08-07 13:50:20
Message-ID: 11C1E6749A55D411A9670001FA687963368042@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> > hstenger(at)adinet(dot)com(dot)uy writes:
> > > My goal is to make the backend accept erroneous commands,
> not falling
> > > in *ABORT STATE*, but rolling back automatically, &
> continue accepting
> > > commands.
> >
> > The way you're doing it, you might as well just not use transaction
> > blocks at all. I don't think wiping out the effects of all
> preceding
> > commands within the transaction counts as "recovering from
> an error".
>
> Ok, maybe I exagerated, but kind of solves my problem.
> GeneXus, my CASE tool,
> will send begin/commit pairs, so I must 'recover'
> automatically. I aimed
> DB2-like behaviour, which I was told, aborts on errors within
> transactions, but
> remains in a runnable state. Don't you consider it valueable
> whatsoever?

DB/2 only aborts the one single statement inside this transaction.
What you did will rollback everything since the last begin work,
and thus is rather dangerous.

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2000-08-07 15:03:24 Re: AW: Questionable coding in proc.c & lock.c
Previous Message Zeugswetter Andreas SB 2000-08-07 13:32:45 AW: pg_dump & performance degradation