On Sun, Jan 16, 2011 at 20:13, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> 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'd think client-side, we have an existing implementation with the
> parallel pg_restore option. Don't know (yet) how easy it is to reuse
> that code…
True.
But however we do it, it will be significantly more complex than just
including the WAL. And I want to make sure we get *something* done in
time for 9.1, and then improve upon it. If we can get the improvement
into 9.1 that's great, but if not it will have to wait until 9.2 - and
I don't want to leave us without anything for 9.1.
>> 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..
>
> You're talking about the pg_streamrecv binary? Then yes, my idea about
> it is that it should become the default archive client we ship with
> PostgreSQL. And grow into offering a way to be the default restore
> command too. I'd see the current way that the standby can switch
> between restoring from archive and from a live stream as a first step
> into that direction.
Right. I did put both the base backup and the wal streaming in the
same binary earlier, and the only shared code was the one to connect
to the db. So I split them apart again. This is the reason to put them
back together perhaps - or just have the ability for pg_basebackup to
fork()+exec() the wal streamer.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
