Hi,

Dimitri Fontaine írta:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>   
>> Seems strange. If you have 2 standbys and you say you would like node1
>> to be the preferred candidate, then you load it so heavily that a remote
>> server with by-definition much larger network delay responds first, then
>> I say your preference was wrong.
>>     
>
> There's a communication mismatch here I think. The problem with the
> dynamic aspect of the system is that the admin wants to plan ahead and
> choose in advance the failover server.
>
> Other than that I much prefer the automatic and dynamic quorum idea.
>
>   
>> If you, Jan and Yeb wish to completely exclude standbys from being part
>> of any quorum, then I guess we need to have per-standby settings to
>> allow that to be defined. I'm in favour of giving people options. That
>> needn't be a mandatory per-standby setting, just a non-default option,
>> so that we can reduce the complexity of configuration for common
>> cases.
>>     
>
> +1
>
>   
>> Maximum Performance => quorum = 0
>> Maximum Availability => quorum = 1, timeout_action = commit
>> Maximum Protection => quorum = 1, timeout_action = shutdown
>>     
>
> +1
>
> Being able to say that a given server has not been granted to
> participate into the vote allowing to reach the global durability quorum
> will allow for choosing the failover candidates.
>
> Now you're able to have this reporting server and know for sure that
> your sync replicated transactions are not waiting for it.
>
> To summarize, the current "per-transaction approach" would be :
>
>  - transaction level replication synchronous behaviour
>   

Sorry for answering such an old mail, but what is the purpose of
a transaction level synchronous behaviour if async transactions
can be held back by a sync transaction?

In my patch, when the transactions were waiting for ack from
the standby, they have already released all their locks, the wait
happened at the latest possible point in CommitTransaction().

In Fujii's patch (I am looking at synch_rep_0722.patch, is there
a newer one?) the wait happens in RecordTransactionCommit()
so other transactions still see the sync transaction and most
importantly, the locks held by the sync transaction will make
the async  transactions waiting for the same lock wait too.

>  - proxy/cascading in core
>  - quorum setup for deciding any commit is safe
>  - any server can be excluded from the sync quorum
>  - timeout can still raises exception or ignore (commit)?
>
> This last point seems to need some more discussion, or I didn't
> understand well the current positions and proposals.
>
> Regards,
>   

Best regards,
Zoltán Böszörményi

In response to

• Re: Synchronization levels in SR at 2010-05-27 11:28:52 from Dimitri Fontaine

Responses

• Re: Synchronization levels in SR at 2010-09-03 11:30:04 from Fujii Masao
• Re: Synchronization levels in SR at 2010-09-06 12:53:07 from Dimitri Fontaine

pgsql-hackers by date

Next:	From: Simon Riggs	Date: 2010-09-03 10:20:09
	Subject: Re: Synchronous replication - patch status inquiry
Previous:	From: PostgreSQL - Hans-Jürgen Schönig	Date: 2010-09-03 09:40:37
	Subject: plan time of MASSIVE partitioning ...