Jim C. Nasby wrote:
> On Mon, Dec 19, 2005 at 07:51:54AM +0000, Simon Riggs wrote:
> > On Sun, 2005-12-18 at 22:03 -0500, Chris Browne wrote:
> > > simon@2ndquadrant.com (Simon Riggs) writes:
> > > > On Sat, 2005-12-10 at 12:07 +0000, Simon Riggs wrote:
> > > >> Following patch implements COPY ... FROM ... LOCK
> > > >
> > > > Patch now updated so that it includes an additional optimization of
> > > > COPY, so that WAL will not be written in the transaction that created
> > > > the table.
> > > >
> > > > This now gives two fast paths for COPY:
> > > > 1) COPY LOCK
> > > > 2) COPY in same transaction (e.g. reloading a pg_dump)
> > >
> > > I presume that if this doesn't go into WAL, that means that this kind
> > > of update wouldn't play with PITR, right?
> >
> > You're right.
> >
> > PITR is designed for normal production use, rather than initial loading.
> > It is also fairly common to turn PITR off permanently in larger data
> > warehouses, which is also where these optimizations are aimed.
>
> Hrm... I'd say we need an option to disable the fast-copy then, in case
> you wanted the copy to make it into PITR. Or perhaps we just disallow
> the fast-copy when PITR is in use. I believe that's what other databases
> do...
Right, just disable with a clear error message.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073