On Sun, Jan 16, 2011 at 20:13, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > Magnus Hagander <mag...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
