Andres Freund <and...@2ndquadrant.com> wrote: > On 2015-01-06 17:08:20 -0800, Josh Berkus wrote: >> On 01/06/2015 04:42 PM, Andres Freund wrote: >>> On 2015-01-06 16:33:36 -0800, Josh Berkus wrote: >>>> F. Inability to remaster without restarting the replica. >>> >>> That has pretty much nothing to do with the topic at hand. >> >> It has *everything* to do with the topic at hand. The *only* reason we >> can't remaster without restarting is that recovery.conf is only read at >> startup time, and can't be reloaded. >> >> http://www.databasesoup.com/2014/05/remastering-without-restarting.html > > Not really. It's a good way to introduce suble and hard to understand > corruption and other strange corner cases. Your replication connection > was lost/reconnected in the wrong moment? Oops, received/replayed too > much.
> A real solution to this requires more. You need to 1) disable writing > any wal 2) force catchup of all possible standbys, including apply. Most > importantly of the new master. This requires knowing which standbys > exist. 3) promote new master. 4) only now allow reconnects. I'm not following. As long as each standby knows what point it is at in the transaction stream, it could make a request to any transaction source for transactions past that point. If a node which will be promoted to the new master isn't caught up to that point, it should not send anything. When it does get caught up it could start sending transactions past that point, including the timeline switch when it is promoted. If you were arguing that some changes besides *just* allowing a standby to read from a new source without a restart, OK -- some changes might also be needed for a promoted master to behave as described above; but certainly the ability to read WAL from a new source on the floor would be a prerequisite, and possibly the biggest hurdle to clear. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
