On 2013-11-21 23:02:29 +0200, Heikki Linnakangas wrote: > On 21.11.2013 22:53, Andres Freund wrote: > >On 2013-11-21 12:51:17 -0800, Josh Berkus wrote: > >>On 11/21/2013 12:46 PM, Andres Freund wrote: > >>>The problem is starting with hot_standby=on on a system with > >>>recovery.conf present. It is independent of whether you use streaming > >>>replication, archive based recovery, or just shutdown the server and > >>>manually copy xlog segments there. > >>>As long as hot_standby=on, and recovery.conf is present you can hit the > >>>bug. > >> > >>Oh, aha. There have to be some transactions which are awaiting > >>checkpoint, though, correct? As in, if there's no activity on the > >>master, you can't trigger the bug? > > > >Correct. Also, if you *start* at such a checkpoint you're not vulnerable > >until the standby is restarted. > > Keep in mind that autovacuum counts as "activity" in this case. If you're > unlucky, that is. It's next to impossible to determine after-the-fact if > there has been activity in the master that might've caused problems.
Well, in that case you're going to "just" loose the pg_database/pg_class/stats updates from analyze/vacuum. That's annoying, but not too bad. > I wouldn't try to narrow it down any further than that, it gets too > complicated. Yes. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
