On Sat, Jul 24, 2010 at 4:40 PM, <z...@cybertec.at> wrote:
> Instead, I will post a patch that unifies my configuration choices with
> Fujii's patch. Do you have suggestions for better worded GUCs?
> "slave" seems to be phased out by "standby" for political correctness, so
> "synchronous_standby" instead of "synchronous_slave". You mentioned
> "min_sync_replication_clients" -> "quorum_min_sync_standbys". What else?
I think that the meaning of my "quorum" parameter is the same as
that of your "min_sync_replication_clients". Right?
I'm planning to add new parameter specifying the behavior of quorum
commit when the number of connected synchronous standbys becomes
less than "quorum".
1. Ignore quorum. If the ACKs from all connected standbys have
arrived, transaction commit is successful even if the number
of standbys is less than quorum. If there is no connected
standby, transaction commit always is successful without
regard to quorum.
2. Observe quorum. Until the number of connected standbys has
become more than or equal to quorum, transaction commit waits.
http://archives.postgresql.org/pgsql-hackers/2010-07/msg01327.php
Is the meaning of this parameter the same as that of your
"strict_sync_replication"?
> You also noticed that my patch addressed 2PC, maybe I will have to add
> this part to Fujii's patch, too. Note: I haven't yet read his patch,
> maybe working with LSNs instead of XIDs make this work automatically,
> I don't know. We should definitely test.
Yeah, transaction commit seems to have to wait for replication in
not only RecordTransactionCommit() but also EndPrepare(),
RecordTransactionCommitPrepared() and RecordTransactionAbortPrepared().
I'll fix that.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
