On Tue, Aug 16, 2011 at 9:32 AM, Magnus Hagander <mag...@hagander.net> wrote: > Here's an updated version of pg_receivexlog, that should now actually > work (it previously failed miserably when a replication record crossed > a WAL file boundary - something which I at the time could not properly > reproduce, but when I restarted my work on it now could easily > reproduce every time :D). > > It also contains an update to pg_basebackup that allows it to stream > the transaction log in the background while the backup is running, > thus reducing the need for wal_keep_segments (if the client can keep > up, it should eliminate the need completely). >
reviewing this... i found useful pg_receivexlog as an independent utility, but i'm not so sure about the ability to call it from pg_basebackup via --xlog option. this is because pg_receivexlog will continue streaming even after pg_basebackup if it's called independently but not in the other case so the use case for --xlog seems more narrow and error prone (ie: you said that it reduces the need for wal_keep_segments *if the client can keep up*... how can we know that before starting pg_basebackup?) pg_receivexlog worked good in my tests. pg_basebackup with --xlog=stream gives me an already recycled wal segment message (note that the file was in pg_xlog in the standby): FATAL: could not receive data from WAL stream: FATAL: requested WAL segment 00000001000000000000005C has already been removed haven't read all the code in the detail but seems fine to me in other things: do we need to include src/bin/pg_basebackup/.gitignore in the patch? -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
