Skip site navigation (1) Skip section navigation (2)

Re: Synchronous commit not... synchronous?

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: Peter van Hardenberg <pvh(at)pvh(dot)ca>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Synchronous commit not... synchronous?
Date: 2012-11-01 05:10:46
Message-ID: CAB7nPqSD_Xr-bgd=cV7O8PmvAJDPfXx_8F_K-0znS7k-9LZZ5g@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Nov 1, 2012 at 1:48 PM, David Fetter <david(at)fetter(dot)org> wrote:

> I guess my disk subsystem (it's a consumer-grade DAS SSD) doesn't have
> enough latency for my reflexes to hit ^C fast enough.  Any way to
> inject this fault deterministically?
>
If the point is to get this warning, you can always setup
synchronous_standby_names with the application name of a slave that is not
listed in pg_stat_replication to make the master hanging for a slave that
does not exist :)
But in this case there is virtually no slave to wait for, so perhaps it has
no meaning... But it lets you all time you want to do a manual cancel and
get this warning.

For example:
postgres=# show synchronous_standby_names;
 synchronous_standby_names
---------------------------
 slave2
(1 row)
postgres=# select application_name, sync_state from pg_stat_replication;
 application_name | sync_state
------------------+------------
 slave1           | async
(1 row)
postgres=# begin;
BEGIN
postgres=# create table aa (a int);
CREATE TABLE
postgres=# commit;
^CCancel request sent
WARNING:  canceling wait for synchronous replication due to user request
DETAIL:  The transaction has already committed locally, but might not have
been replicated to the standby.
COMMIT
postgres=# show synchronous_commit;
 synchronous_commit
--------------------
 on
(1 row)
postgres=# \d
        List of relations
 Schema | Name | Type  |  Owner
--------+------+-------+---------
 public | aa   | table | michael
(1 row)

Btw, I believe that this is correct behavior, because in Peter's case the
manual command gets the priority on the value of synchronous_commit, no?
If anybody thinks that I am wrong, feel free to argue on that of course...
-- 
Michael Paquier
http://michael.otacoo.com

In response to

Responses

pgsql-hackers by date

Next:From: David FetterDate: 2012-11-01 05:24:26
Subject: Re: Synchronous commit not... synchronous?
Previous:From: David FetterDate: 2012-11-01 04:48:13
Subject: Re: Synchronous commit not... synchronous?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group