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
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2011-01-16 18:20:54|
|Subject: Re: We need to log aborted autovacuums |
|Previous:||From: Greg Smith||Date: 2011-01-16 18:08:36|
|Subject: Re: We need to log aborted autovacuums|