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

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 (view raw or flat)
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

pgsql-hackers by date

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

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