From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Add psql option: -1 or --single-transaction |
Date: | 2006-02-14 16:00:47 |
Message-ID: | 1139932847.1258.958.camel@localhost.localdomain |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On Tue, 2006-02-14 at 09:57 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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 | Content-Type | Size |
---|---|---|
1withblobs.patch | text/x-patch | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-02-14 16:39:32 | pgsql: Add some missing vacuum_delay_point calls in GIST vacuuming. |
Previous Message | User H-saito | 2006-02-14 15:50:14 | psqlodbc - psqlodbc: Correction of Dialog font. |