Bruce Momjian wrote:
> I just checked and pg_dump -d _doesn't_ place the INSERT's in a
> transsaction. Seems it should, and perhaps add a:
>
> SET autocommit TO 'on'
>
> as well. Of course, that SET would fail when restoring to prior
> releases, but they don't have autocommit off anyway so it can be
> ignored. Comments? This would certainly speed up loads that use
> INSERT.
I'm not sure that pg_dump is the right place to do this, unless it's
something that can be turned on/off with a command line switch
(remember that editing the file to delete or comment out the
transaction commands isn't necessarily feasible). It seems to me that
a DBA might want to have a bit more control over this behavior.
So: if pg_restore or some other utility is used to perform the
restore, then that utility should issue the BEGIN/END on behalf of the
user.
One reason I can think of for keeping manual control over the
transaction is the case where one wishes to restore from multiple
dumps. In that case, it could be very useful to issue a single
transaction block around the entire thing, and to examine the restored
data before actually committing the results, in case something doesn't
look right.
This is all complicated, of course, by commands which cannot occur
within transactions, which is why I think a switch controlling this
behavior is appropriate. I certainly don't have a problem with the
default being that the transaction commands are issued in the dump, as
long as it's a behavior that can be turned off.
--
Kevin Brown kevin@sysexperts.com
