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

Re: NOLOGGING option, or ?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Jochem van Dieten <jochemd(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: NOLOGGING option, or ?
Date: 2005-06-01 14:14:42
Message-ID: 200506011414.j51EEge20648@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Jochem van Dieten wrote:
> On 01 Jun 2005 04:44:24 -0400, Greg Stark wrote:
> > Greg Stark writes:
> >> 
> >> For CREATE TABLE AS in the non-PITR case you don't really need to WAL log the
> >> records at all. If it fails in the middle you just drop the table. When it
> >> completes you do a checkpoint before acknowledging the COMMIT.
> >>
> >> I think this is already done for CREATE INDEX/REINDEX, also only in the
> >> non-PITR case.
> 
> Checkpoint or fsync?
> 
> 
> > Sorry to followup to my own message, but it occurs to me that COPY could be
> > made to automatically do this for the case of an empty destination table too.
> 
> Why only on an empty table? What is the problem with bypassing WAL on
> any table as long as all files of that table are fsync'ed before
> commit?

Because adding rows to a table might modify existing pages, and if the
COPY fails, you have to restore those pages to a consistent state, and
make sure they are recovered for partial page writes, which we can't do
without WAL.  With an initially empty table, you can just throw away the
file system file.

-- 
  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

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-06-01 14:18:25
Subject: Re: NOLOGGING option, or ?
Previous:From: Tom LaneDate: 2005-06-01 14:12:34
Subject: Re: Quick-and-dirty compression for WAL backup blocks

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