Re: pgsql: Add psql option: -1 or --single-transaction - Mailing list pgsql-committers

From Simon Riggs
Subject Re: pgsql: Add psql option: -1 or --single-transaction
Date
Msg-id 1139932847.1258.958.camel@localhost.localdomain
Whole thread Raw
In response to Re: pgsql: Add psql option: -1 or --single-transaction  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Add psql option: -1 or --single-transaction  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pgsql: Add psql option: -1 or --single-transaction  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pgsql: Add psql option: -1 or --single-transaction  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
List pgsql-committers
On Tue, 2006-02-14 at 09:57 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > How should it work?
>
> > 1. Remove the BEGIN and COMMIT around blobs?
> > 2. Use SAVEPOINT ?
>
> > Presumably (1).
>
> Yeah, there is no need for the per-blob begin/commit if we've got one
> around the whole restore.

Just put an if test around that blob-handling behaviour. The code looks
very simple, so patch enclosed to augment the already-applied patch.

Chris, do you have a set-up to test out the blob behaviour? If your
using them in production you'll spot any further slip-ups; they weren't
intentionally ignored in the original patch.

> One thing to be careful of is not to suppress BEGINs that are sent on
> the dumping side --- it's sometimes hard to tell which parts of pg_dump
> execute when.

Not touched, nothing fancy going on.

[It's a shame we don't support nested BEGINs, for use in nested function
calls. I guess we took that out infavour of SAVEPOINTs? I seem to
remember some idiot (me wasn't it?) suggesting we should do that.]

Best Regards, Simon Riggs

Attachment

pgsql-committers by date:

Previous
From: h-saito@pgfoundry.org (User H-saito)
Date:
Subject: psqlodbc - psqlodbc: Correction of Dialog font.
Next
From: tgl@postgresql.org (Tom Lane)
Date:
Subject: pgsql: Add some missing vacuum_delay_point calls in GIST vacuuming.