Re: [HACKERS] Errors inside transactions
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Errors inside transactions |
Дата | |
Msg-id | 18621.906396416@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Errors inside transactions ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
"Thomas G. Lockhart" <lockhart@alumni.caltech.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 по дате отправления: