Re: transaction error handling
От | Craig Ringer |
---|---|
Тема | Re: transaction error handling |
Дата | |
Msg-id | 4ED6BE16.5090706@ringerc.id.au обсуждение исходный текст |
Ответ на | Re: transaction error handling ("Nicholson, Brad (Toronto, ON, CA)" <bnicholson@hp.com>) |
Список | pgsql-admin |
On 11/30/2011 09:19 PM, Nicholson, Brad (Toronto, ON, CA) wrote: > This functionality is something that Postgres can do today. We expose > the ability to do this with explicit savepoints. The difference is > that Oracle allows you to set it on a per transaction basis (I > believe) and it will behave this way for all statements in the > transaction, where as we need to do it explicitly. Looking through the > archives there does seem to be a performance problem on commit in > Postgres if you issue a lot of savepoints (there were discussions of a > fix but I am not sure the status of this). Savepoint performance has had several improvements over time. Back in 8.1 when I got started developing against Pg seriously I was having *MASSIVE* performance issues with PL/PgSQL exception blocks (which use savepoints) in loops; these days it's perfect. To make automatic savepoints viable, Pg would need to be able to completely forget a savepoint once it's been released, so there's no ongoing cost. That way a transaction would only need two savepoints at any particular point in time. My understanding is that it's not there yet; AFAIK released savepoints still have a non-trivial cost that would add up if someone was using automatic savepoints in (say) a 10,000 INSERT transaction. -- Craig Ringer
В списке pgsql-admin по дате отправления: