At this point I feel that this new functionality might be a bit
overkill for postgres, maybe it's better to stay lean and mean rather
than add a controversial feature like this.
I also agree that a more general replication timeout variable would be
more useful to a larger audience but that would i
Okay,
Here’s version 3 then, which piggy-backs on the existing flag :
synchronous_commit = on | off | local | fallback
Where “fallback” now means “fall back from sync replication when no
(suitable) standbys are connected”.
This was done on input from Guillaume Lelarge.
> That said, I agree it'
On Mon, Dec 26, 2011 at 5:18 PM, Guillaume Lelarge
wrote:
> On Mon, 2011-12-26 at 16:23 +0100, Magnus Hagander wrote:
>> On Mon, Dec 26, 2011 at 15:59, Alexander Björnhagen
>> wrote:
>> >>>> Basically I like this whole idea, but I'd like to know why do yo
Hmm,
I suppose this conversation would lend itself better to a whiteboard
or a maybe over a few beers instead of via e-mail ...
> Basically I like this whole idea, but I'd like to know why do you think
> this functionality is required?
How should a synchronous master handle the si
Interesting discussion!
>>> Basically I like this whole idea, but I'd like to know why do you think
>>> this functionality is required?
>> How should a synchronous master handle the situation where all
>> standbys have failed ?
>>
>> Well, I think this is one of those cases where you could argue
Hello and thank you for your feedback I appreciate it.
Updated patch : sync-standalone-v2.patch
I am sorry to be spamming the list but I just cleaned it up a little
bit, wrote better comments and tried to move most of the logic into
syncrep.c since that's where it belongs anyway and also fixed a
Hi all,
I’m new here so maybe someone else already has this in the works ?
Anyway, proposed change/patch :
Add a new parameter :
synchronous_standalone_master = on | off
To control whether a master configured with synchronous_commit = on is
allowed to stop waiting for standby WAL sync when all
