Skip site navigation (1) Skip section navigation (2)

Re: COPY LOCK for WAL bypass

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-patches(at)postgresql(dot)org
Subject: Re: COPY LOCK for WAL bypass
Date: 2005-12-21 13:17:46
Message-ID: 200512211317.jBLDHkt03827@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Simon Riggs wrote:
> On Sun, 2005-12-18 at 22:03 -0500, Chris Browne wrote:
> > simon(at)2ndquadrant(dot)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.
> 
> I'll take the hint and write the docs then. :-)

I assume in addition to a documentation mention, you will disable this
feature when PITR is on, right?  (Rather than just document something
that is unsafe, we disable it.)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-patches by date

Next:From: Bruce MomjianDate: 2005-12-21 13:18:15
Subject: Re: COPY LOCK for WAL bypass
Previous:From: Sagi BashariDate: 2005-12-21 12:18:51
Subject: BUG #2120: Crash when doing UTF8<->ISO_8859_8 encoding conversion

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group