On Tue, Aug 16, 2011 at 9:32 AM, Magnus Hagander <magnus@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
