On Sun, Apr 15, 2012 at 12:13 AM, Thom Brown <t...@linux.com> wrote: > On 14 April 2012 15:58, Fujii Masao <masao.fu...@gmail.com> wrote: >> On Sat, Apr 14, 2012 at 4:16 AM, Thom Brown <t...@linux.com> wrote: >>> I have a question though. What happens when this is set to "write" >>> (or "remote_write" as proposed) but it's being used on a standalone >>> primary? At the moment it's not documented what level of guarantee >>> this would provide. >> >> http://www.postgresql.org/docs/devel/static/warm-standby.html#SYNCHRONOUS-REPLICATION-HA >> ----------------- >> Commits made when synchronous_commit is set to on or write will >> wait until the synchronous standby responds. The response may >> never occur if the last, or only, standby should crash. >> ----------------- >> >> Is this description not enough? If not enough, how should we change >> the document? > > No, that's not what I was referring to. If you don't have a standby > (i.e. a single, isolated database cluster with no replication), and > its synchronous_commit is set to 'remote_write', what effect does that > have?
It's the same effect as 'on' and 'local' do, i.e., transaction commit waits for only local WAL flush. This behavior is not documented explicitly... How should we change the document? What about adding the following into the explanation of synchronous_commit parameter (maybe the end of second paragraph of that)? ----------------- If synchronous_standby_names is not set, on, remote_write and local provide the same synchronization level; transaction commit only waits for local flush. ----------------- Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
