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