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

Re: [HACKERS] Errors inside transactions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Errors inside transactions
Date: 1998-09-21 16:46:56
Message-ID: 18621.906396416@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Thomas G. Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> Why not have your error handler issue a new BEGIN statement? Or an
> END/BEGIN pair if that is what is needed? afaik that wouldn't be any
> different than the proposed "CONTINUE TRANSACTION" statement.
> Or do you really want to commit the previous statements in the
> transaction rather than throw them away? If so, you didn't really need
> the transaction block there anyway, since you are willing to accept a
> partial result.

You're right, I don't especially need or want the rollback aspect of
transactions.  This is a shared database with half a dozen processes
watching it, and what I do want is to ensure that the other processes
will not see the logically-inconsistent state that occurs while updating
several related tuples with multiple UPDATE commands.

I guess what I'd really like is to be able to separate the atomic-update
and rollback features of transactions.  If I could use "LOCK relation"
without having to be inside a transaction, I'd be a much happier camper.
(This'd at least imply an UNLOCK statement, I suppose.  Are there deeper
relationships between locks and transactions?)

			regards, tom lane

pgsql-hackers by date

Next:From: Thomas G. LockhartDate: 1998-09-21 17:04:08
Subject: Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]
Previous:From: Thomas G. LockhartDate: 1998-09-21 16:38:24
Subject: Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]

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