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:

Reply via email to