Re: Fast index build vs. PITR

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Subject: Re: Fast index build vs. PITR
Date: 2004-06-01 20:31:22
Message-ID: 1086121881.3258.270.camel@stromboli
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2004-06-01 at 03:21, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > I assume if someone turns on archiving in postgresql.conf, sighups the
> > > postmaster, then does a tar backup, they should be able to do archiving,
> > > no?
> >
> > I would have zero problem with labeling the archive parameter as
> > changeable only at postmaster start.
>
> I guess the question is whether it would be possible to start/stop it at
> other times. And what process are we going to use to do a tar backup?
> Do they turn off archiving before doing the tar, or tell the system to
> tar to another location?
>

This situation has been discussed and agreed twice already. First we
discussed it was SUSET, then SIGHUP, now we talk about postmaster
startup.

I'm not sure I'm too bothered either way, but the code has now been
written to make it a SIGHUP operation. Making it SIGHUP effects the way
we invoke the archiver process at postmaster startup, so if we want to
change things again we must do so real soon.

Postmaster startup is the simplest scenario at run-time, so I'd suggest
we move to that NOW and then MAYBE back to SIGHUP at a later time, when
we are more certain everything works in production.

> And you brought up the issue of how do we feed multilple archive files
> back into the xlog directory during restore if they don't all fit on the
> disk.
>

That has already been requested by Tom and agreed as on-the-PITR feature
list as an embellishment of the general recover-to-a point scenario. It
*MIGHT* make it into this release, if we get the other stuff done first.

> I think we need to explore the procedures we are going to use for PITR.
>

Much of that has already been discussed.

Best Regards, Simon Riggs

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2004-06-01 21:05:07 Re: Converting postgresql.conf parameters to kilobytes
Previous Message Simon Riggs 2004-06-01 20:29:12 Re: Fast index build vs. PITR