Re: NOLOGGING option, or ?

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Alvaro Herrera <alvherre(at)surnet(dot)cl>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: NOLOGGING option, or ?
Date: 2005-06-01 12:03:25
Message-ID: 1117627405.3844.950.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2005-06-01 at 04:44 -0400, Greg Stark wrote:
> Greg Stark <gsstark(at)MIT(dot)EDU> 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.
>
> 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.
>
> I'm not sure if it should automatically check for an empty table or if there
> should be an option for the user to indicate he wants COPY to replace the
> current contents entirely. The latter might actually be more useful. .
>
> But either way, you just WAL log a record indicating that the table should be
> entirely empty. Then you fill it up without logging anything. Do a checkpoint
> and then WAL log that the COPY is finished. If any failure occurs replay
> leaves it empty.
>
> Again this sadly only works in the non-PITR case.

Yes, all of the above could work.

It would use essentially the same functionality that Manfred suggested
for handling truncated tables. Ignore the first LOAD DATA started
message until recovery completes, then truncate table if the LOAD DATA
complete message was not logged in wal.

Best Regards, Simon Riggs

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2005-06-01 12:10:55 Re: NOLOGGING option, or ?
Previous Message Dawid Kuroczko 2005-06-01 12:00:41 Re: Tablespace-level Block Size Definitions