On 04/29/2015 06:03 AM, Stephen Frost wrote:
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7173,7 +7173,10 @@ StartupXLOG(void)
* than is appropriate now that we're not in standby mode anymore.
*/
if (fast_promoted)
+ {
+ sleep(5);
RequestCheckpoint(CHECKPOINT_FORCE);
+ }
}
The simplest fix would be to force a checkpoint in the regression
test, before running pg_rewind. It's a bit of a cop out, since you'd
still get the same issue when you tried to do the same thing in the
real world. It should be rare in practice - you'd not normally run
pg_rewind immediately after promoting the standby - but a better
error message at least would be nice..
Forcing a checkpoint in the regression tests and then providing a better
error message sounds reasonable to me. I agree that it's very unlikely
to happen in the real world, even when you're bouncing between systems
for upgrades, etc, you're unlikely to do it fast enough for this issue
to exhibit itself, and a better error message would help any users who
manage to run into this (perhaps during their own testing).
I've committed this simple fix for now.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
