On Sun, Apr 15, 2012 at 12:13 AM, Thom Brown <thom(at)linux(dot)com> wrote:
> On 14 April 2012 15:58, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Sat, Apr 14, 2012 at 4:16 AM, Thom Brown <thom(at)linux(dot)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.
>> 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
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
In response to
pgsql-hackers by date
|Next:||From: Alex||Date: 2012-04-16 16:24:12|
|Subject: Bug tracker tool we need (was: Last gasp)|
|Previous:||From: Hannu Krosing||Date: 2012-04-16 16:19:40|
|Subject: Re: JSON for PG 9.2|
pgsql-committers by date
|Next:||From: Peter Eisentraut||Date: 2012-04-16 19:41:40|
|Subject: pgsql: Add compatibility information for prepared transaction commands|
|Previous:||From: Peter Eisentraut||Date: 2012-04-16 12:37:14|
|Subject: pgsql: Fix typo|