On Wed, May 16, 2012 at 1:36 AM, Thom Brown <thom@linux.com> wrote:
> However, this isn't true when I restart the standby. I've been
> informed that this should work fine if a WAL archive has been
> configured (which should be used anyway).
The WAL archive should be shared by master-replica and replica-replica,
and recovery_target_timeline should be set to latest in replica-replica.
If you configure that way, replica-replica would successfully reconnect to
master-replica with no need to restart it.
> But one new problem I appear to have is that once I set up archiving
> and restart, then try pg_basebackup, it gets stuck and never shows any
> progress. If I terminate pg_basebackup in this state and attempt to
> restart it more times than max_wal_senders, it can no longer run, as
> pg_basebackup didn't disconnect the stream, so ends up using all
> senders. And these show up in pg_stat_replication. I have a theory
> that if archiving is enabled, restart postgres then generate some WAL
> to the point there is a file or two in the archive, pg_basebackup
> can't stream anything. Once I restart the server, it's fine and
> continues as normal. This has the same symptoms of the "pg_basebackup
> from running standby with streaming" issue.
This seems to be caused by spread checkpoint which is requested by
pg_basebackup. IOW, this looks a normal behavior rather than a bug
or an issue. What if you specify "-c fast" option in pg_basebackup?
Regards,
--
Fujii Masao
