On 03/09/10 09:36, Simon Riggs wrote:
On Fri, 2010-09-03 at 12:50 +0900, Fujii Masao wrote:
That design would affect what the standby should reply. If we choose
async/recv/fsync/replay on a per-transaction basis, the standby
should send multiple LSNs and the master needs to decide when
replication has been completed. OTOH, if we choose just sync/async,
the standby has only to send one LSN.
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.
Please explain how you do it then. When a commit record is sent to the
standby, it needs to acknowledge it 1) when it has received it, 2) when
it fsyncs it to disk and c) when it's replayed. I don't see how you can
get around that.
Perhaps you can save a bit by combining multiple messages together, like
in Nagle's algorithm, but then you introduce extra delays which is
exactly what you don't want.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
