Fujii, Wait, are you telling me that we *still* can't remaster from streaming replication? Why wasn't that fixed in 9.2?
And: if we still have to ship logs, what's the point in even having cascading replication? ----- Original Message ----- > On Wed, May 16, 2012 at 1:36 AM, Thom Brown <t...@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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
