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

Re: Include WAL in base backup

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Include WAL in base backup
Date: 2011-01-16 18:16:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, Jan 16, 2011 at 18:45, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>> What if you start a concurrent process that begins streaming the WAL
>>> segments just before you start the backup, and you stop it after having
>>> stopped the backup.  I would think that then, the local received files
>>> would be complete.  We would only need a program able to stream the WAL
>>> segments and build WAL files from that… do you know about one? :)
>> Sure, if you stream the backups "on the side", then you don't need
>> this feature. This is for "very simple filesystem backups", without
>> the need to set up streaming of archiving.
> What I meant is: why don't we provide an option to automate just that
> behavior in pg_basebackup?  It looks like a fork() then calling code you
> already wrote.

Ah, I see. That's a good idea.

However, it's not quite that simple. "just adding a fork()" doesn't
work on all our platforms, and you need to deal with feedback and such
between them as well.

I think it's definitely something worth doing in the long run, but I
think we should start with the simpler way.

Oh, and this might be the use-case for integrating the streaming log
code as well :-) But if we plan to do that, perhaps we should pick a
different name for the binary? Or maybe just share code with another
one later..

 Magnus Hagander

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-01-16 18:20:54
Subject: Re: We need to log aborted autovacuums
Previous:From: Greg SmithDate: 2011-01-16 18:08:36
Subject: Re: We need to log aborted autovacuums

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