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