From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sync Rep: First Thoughts on Code |
Date: | 2008-12-16 10:21:10 |
Message-ID: | 1229422870.8673.424.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2008-12-16 at 12:36 +0900, Fujii Masao wrote:
> > So from my previous list
> >
> > 1. We sent the message to standby (A)
> > 2. We received the message on standby
> > 3. We wrote the WAL to the WAL file (B)
> > 4. We fsync'd the WAL file (C)
> > 5. We CRC checked the WAL commit record
> > 6. We applied the WAL commit record
> >
> > Please could you also add an option #4, i.e. add the *option* to fsync
> > the WAL to disk at commit time also. That requires us to add a third
> > option to synchronous_replication parameter.
>
> The above option should be configured on the primary? or standby?
> The primary is suitable to vary it from transaction to transaction. On
> the other hand, it should be configured on the standby in order to
> choose it for every standby (in the future).
>
> I prefer the latter, and thought that it should be added into recovery.conf.
> I mean, synchronous_replication identifies only whether commit waits for
> replication (if the name is confusing, I would rename it). The above
> options (#1-#6) are chosen in recovery.conf. What is your opion?
No, we've been through that loop already a few months back:
Transaction-controlled robustness.
It should be up to the client on the primary to decide how much waiting
they would like to perform in order to provide a guarantee. A change of
setting on the standby should not be allowed to alter the performance or
durability on the primary.
My perspective is that synchronous_replication specifies how long to
wait. Current settings are "off" (don't wait) or "on" (meaning wait
until point #3). So I think we should change this to a list of options
to allow people to more carefully select how much waiting is required.
This feature is then analogous to the way synchronous_commit works. It
also provides a level of application control not seen in any other RDBMS
in the industry, which makes it very suitable for large and important
applications that need a fine mix of robustness and performance.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | A. Kretschmer | 2008-12-16 10:29:02 | Re: non unique value error... pgsql,,help needed. |
Previous Message | Dave Page | 2008-12-16 10:13:01 | Re: pgsql: Append major version number and for libraries soname major |