Re: Sample archive_command is still problematic

Magnus Hagander <magnus@hagander.net> wrote:

> On Wed, Aug 13, 2014 at 11:23 PM, Kevin Grittner <kgrittn@ymail.com> wrote:

>
>> The above is regarding WAL file archiving -- I'm not putting down
>> streaming replication.  Of course, what I would have *really* liked
>> is a WAL receiver that could write out normal-looking WAL files for
>> archiving purposes and pass through the WAL stream to a hot
>> standby.  Last I checked (which was admittedly at least a couple
>> years back) there was no such utility, although I seem to remember
>> that Magnus had done some work that looked like it could be bent to
>> that end.
>
> I did. But I think that has mostly been superceded by replication
> slots now. As in, if you use pg_receivexlog with a specific
> replication slot, I believe you no longer need archive command at all,
> do you? Since the replication slot will block rotation of the WAL
> files until they are actually archived by pg_receivexlog (What my
> command did was have an archive command that looked back into
> pg_stat_replication to see if pg_receivexlog had received the data or
> not).
>
> It did not pass through any WAL stream though - you'd have your
> standby connect directly to the same master that pg_receivexlog
> connects to. What would be the actual reason for having that one do
> the passthrough itself?

The use case was to maintain both a hot standby and a set of WAL
files to allow PITR recovery (e.g., to recover to just before some
catastrophic SQL command was executed) to a remote site across a
*slow* WAN connection.  Rather than send the WAL across the slow
connection twice they would ship and apply WAL files and suffer the
consequent replication delay to the hot standby; but if the standby
could be done through streaming replication and the WAL files could
still be re-created off of the same stream, that would be better.

Basically, where bandwidth is limited and expensive, you don't want
to have to send the same WAL data over the same connection more
than once.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company