Re: Synchronous replication - patch status inquiry - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Synchronous replication - patch status inquiry
Date
Msg-id 10872.1283874112@sss.pgh.pa.us
Whole thread Raw
In response to Re: Synchronous replication - patch status inquiry  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Synchronous replication - patch status inquiry  (Robert Haas <robertmhaas@gmail.com>)
Re: Synchronous replication - patch status inquiry  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Tue, 2010-09-07 at 10:47 -0400, Tom Lane wrote:
>> Simon Riggs <simon@2ndQuadrant.com> writes:
>>> The WAL is sent from master to standby in 8192 byte chunks, frequently
>>> including multiple commits. From standby, one reply per chunk. If we
>>> need to wait for apply while nothing else is received, we do. 
>> 
>> That premise is completely false.  SR does not send WAL in page units.
>> If it did, it would have the same performance problems as the old
>> WAL-file-at-a-time implementation, just with slightly smaller
>> granularity.

> There's no dependence on pages in that proposal, so don't understand.

Oh, well you certainly didn't explain it well then.

What I *think* you're saying is that the slave doesn't send per-commit
messages, but instead processes the WAL as it's received and then sends
a heres-where-I-am status message back upstream immediately before going
to sleep waiting for the next chunk.  That's fine as far as the protocol
goes, but I'm not convinced that it really does all that much in terms
of improving performance.  You still have the problem that the master
has to fsync its WAL before it can send it to the slave.  Also, the
slave won't know whether it ought to fsync its own WAL before replying.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: PgWest 2010 CFP extended (one week)
Next
From: Tom Lane
Date:
Subject: Re: Synchronization levels in SR