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

Re: Synchronous replication - patch status inquiry

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, fazool mein <fazoolmein(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Synchronous replication - patch status inquiry
Date: 2010-09-03 07:08:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Sep 3, 2010 at 3:36 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> The former seems to be more useful, but triples the number of ACK
>> from the standby. I'm not sure whether its overhead is ignorable,
>> especially when the distance between the master and the standby is
>> very long.
> No, it doesn't. There is no requirement for additional messages. It just
> adds 16 bytes onto the reply message, maybe 24. If there is a noticeable
> overhead from that, shoot me.

The reply message would be sent at least three times every WAL chunk,
i.e., when the standby has received, synced and replayed it. So ISTM
that additional messagings happen. Though I'm not sure if this really
harms the performance...

You'd like to choose async/recv/fsync/replay on a per-transaction basis
rather than async/sync?

Even when async is chosen as the synchronization level in standbys.conf,
it can be changed to other level in transaction? If so, the standby has
to send the reply even if async is chosen and most replies might be
ignored in the master.


Fujii Masao
NTT Open Source Software Center

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-09-03 07:45:30
Subject: Re: Synchronous replication - patch status inquiry
Previous:From: Heikki LinnakangasDate: 2010-09-03 06:55:37
Subject: Re: Synchronous replication - patch status inquiry

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