Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id A59B3A0109C for ; Wed, 30 Nov 2011 19:37:18 -0400 (AST) Received: from mail-ey0-f174.google.com ([209.85.215.174]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RVtiG-0001ET-Oc for pgsql-admin@postgresql.org; Wed, 30 Nov 2011 23:37:18 +0000 Received: by eaak14 with SMTP id k14so1382070eaa.19 for ; Wed, 30 Nov 2011 15:37:03 -0800 (PST) Received: by 10.213.14.72 with SMTP id f8mr96611eba.127.1322696223095; Wed, 30 Nov 2011 15:37:03 -0800 (PST) Received: from ayaki.localdomain (124-169-45-65.dyn.iinet.net.au. [124.169.45.65]) by mx.google.com with ESMTPS id 8sm11468414eei.8.2011.11.30.15.36.58 (version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 15:37:01 -0800 (PST) Message-ID: <4ED6BE16.5090706@ringerc.id.au> Date: Thu, 01 Dec 2011 07:36:54 +0800 From: Craig Ringer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Nicholson, Brad (Toronto, ON, CA)" CC: Rob Richardson , "pgsql-admin@postgresql.org" Subject: Re: transaction error handling References: <28131.1322067903@sss.pgh.pa.us> <232B5217AD58584C87019E8933556D11036BDE58EB@redmx2.esri.com> <67D108EDFAD3C148A593E6ED7DCB4BBDEDDBAE@RADCONWIN2K8PDC.radcon.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201111/163 X-Sequence-Number: 38757 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