Andres Freund <andres@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