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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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