Re: [RFC] What should we do for reliable WAL archiving? - Mailing list pgsql-hackers

From MauMau
Subject Re: [RFC] What should we do for reliable WAL archiving?
Date
Msg-id 4D837AAE66BA4BE980F13FC061E86FC1@maumau
Whole thread Raw
In response to Re: [RFC] What should we do for reliable WAL archiving?  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [RFC] What should we do for reliable WAL archiving?  (Andreas Karlsson <andreas@proxel.se>)
Re: [RFC] What should we do for reliable WAL archiving?  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
From: "Amit Kapila" <amit.kapila16@gmail.com>
> How about using pg_receivexlog for archiving purpose?

pg_receivexlog is good in that it does fsync().  But it seems difficult to 
use correctly, and I'm not sure if I can catch all WAL segments without any 
loss.  pg_receivexlog must be started with postmaster and monitored with 
some measures.  This won't be very easy at least on Windows.

The pg_receivexlog reference page suggests another difficulty:

Notes
When using pg_receivexlog instead of archive_command, the server will 
continue to recycle transaction log files even if the backups are not 
properly archived, since there is no command that fails. This can be worked 
around by having an archive_command that fails when the file has not been 
properly archived yet, for example:
archive_command = 'sleep 5 && test -f /mnt/server/archivedir/%f'

This suggestion is not correct, because it only checks the existence of the 
file.  What if the file size is less than 16MB?  How can we check if the 
file is completely archived?

Regards
MauMau




pgsql-hackers by date:

Previous
From: "Erik Rijkers"
Date:
Subject: Re: jsonb status - 'JsonbValue' has no member named 'size'
Next
From: Craig Ringer
Date:
Subject: Re: requested shared memory size overflows size_t