Re: little PITR annoyance - Mailing list pgsql-hackers

From ohp@pyrenet.fr
Subject Re: little PITR annoyance
Date
Msg-id Pine.UW2.4.53.0706102044400.13477@sun.pyrenet
Whole thread Raw
In response to Re: little PITR annoyance  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: little PITR annoyance
List pgsql-hackers
Hi Simon,
Sorry for replying so late...
On Fri, 8 Jun 2007, Simon Riggs wrote:

> Date: Fri, 08 Jun 2007 20:16:35 +0100
> From: Simon Riggs <simon@2ndquadrant.com>
> To: ohp@pyrenet.fr
> Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
> Subject: Re: [HACKERS] little PITR annoyance
>
> Hi Olivier,
>
> On Fri, 2007-06-08 at 11:41 +0200, ohp@pyrenet.fr wrote:
> > The problem is not with gzip or scp, it is that postmaster refuses to
> > start because wal FS is full.
>
> > My questions was: why don't we start the archiving *BEFORE* postmaster to
> > make room.
>
> The archiver is executed from the postmaster, so thats not possible.
>
I'm aware of that, my point is maybe the archiver doesn't need postmaster
to be fully operational  (responding to db requests) to be started
> We could investigate where best to put some code, but it wouldn't be
> executed very frequently.
I agree, OTOH, the more PITR is used on big busy db to more this may
happend.
>
> Why not just execute the archive_command in a script, replacing
> the .ready with .done files in archive_status directory when its
> processed?
>
Sure, but if *I* can do it, why can't the system?

What do you think,
>
Best regards,
-- 
Olivier PRENANT                    Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges                +33-5-61-50-97-01 (Fax)
31190 AUTERIVE                       +33-6-07-63-80-64 (GSM)
FRANCE                          Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)


pgsql-hackers by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: Avoiding legal email signatures
Next
From: Heikki Linnakangas
Date:
Subject: Re: Controlling Load Distributed Checkpoints