Synchronous replication
in [PgSql]
|
From: Yeb Havinga on 26 Jul 2010 05:36 Fujii Masao wrote: > I still like > > replication_mode = {async|recv|fsync|replay} > > rather than > > synchronous_replication = {on|off} > acknowledge_commit = {no|recv|fsync|replay} > Hello Fujii, I wasn't entirely clear. My suggestion was to have only acknowledge_commit = {no|recv|fsync|replay} instead of replication_mode = {async|recv|fsync|replay} regards, Yeb Havinga -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 26 Jul 2010 06:44 On Mon, Jul 26, 2010 at 6:36 PM, Yeb Havinga <yebhavinga(a)gmail.com> wrote: > Fujii Masao wrote: >> >> I still like >> >> � �replication_mode = {async|recv|fsync|replay} >> >> rather than >> >> � �synchronous_replication = {on|off} >> � �acknowledge_commit = {no|recv|fsync|replay} >> > > Hello Fujii, > > I wasn't entirely clear. My suggestion was to have only > > � acknowledge_commit = {no|recv|fsync|replay} > > instead of > > � replication_mode = {async|recv|fsync|replay} Okay, I'll change the patch accordingly. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Marko Tiikkaja on 26 Jul 2010 06:48 On 7/26/10 1:44 PM +0300, Fujii Masao wrote: > On Mon, Jul 26, 2010 at 6:36 PM, Yeb Havinga<yebhavinga(a)gmail.com> wrote: >> I wasn't entirely clear. My suggestion was to have only >> >> acknowledge_commit = {no|recv|fsync|replay} >> >> instead of >> >> replication_mode = {async|recv|fsync|replay} > > Okay, I'll change the patch accordingly. For what it's worth, I think replication_mode is a lot clearer. Acknowledge_commit sounds like it would do something similar to asynchronous_commit. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 26 Jul 2010 07:25 On Mon, Jul 26, 2010 at 6:48 AM, Marko Tiikkaja <marko.tiikkaja(a)cs.helsinki.fi> wrote: > On 7/26/10 1:44 PM +0300, Fujii Masao wrote: >> >> On Mon, Jul 26, 2010 at 6:36 PM, Yeb Havinga<yebhavinga(a)gmail.com> �wrote: >>> >>> I wasn't entirely clear. My suggestion was to have only >>> >>> � acknowledge_commit = {no|recv|fsync|replay} >>> >>> instead of >>> >>> � replication_mode = {async|recv|fsync|replay} >> >> Okay, I'll change the patch accordingly. > > For what it's worth, I think replication_mode is a lot clearer. > Acknowledge_commit sounds like it would do something similar to > asynchronous_commit. I agree. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Joshua Tolley on 26 Jul 2010 23:36
On Thu, Jul 22, 2010 at 10:37:12AM +0200, Yeb Havinga wrote: > Fujii Masao wrote: > Initially I also expected the quorum to behave like described by > Aidan/option 2. Also, IMHO the name "quorom" is a bit short, like having > "maximum" but not saying a max_something. > > quorum_min_sync_standbys > quorum_max_sync_standbys Perhaps I'm hijacking the wrong thread for this, but I wonder if the quorum idea is really the best thing for us. I've been thinking about Oracle's way of doing things[1]. In short, there are three different modes: availability, performance, and protection. "Protection" appears to mean that at least one standby has applied the log; "availability" means at least one standby has received the log info (it doesn't specify whether that info has been fsynced or applied, but presumably does not mean "applied", since it's distinct from "protection" mode); "performance" means replication is asynchronous. I'm not sure this method is perfect, but it might be simpler than the quorum behavior that has been considered, and adequate for actual use cases. [1] http://download.oracle.com/docs/cd/B28359_01/server.111/b28294/protection.htm#SBYDB02000 alternatively, http://is.gd/dLkq4 -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com |