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

Re: Synchronous replication - patch status inquiry

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Fujii Masao <masao(dot)fujii(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-07 16:07:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Sep 7, 2010 at 11:59 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> 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.
> Yes, apart from last sentence. Please wait for the code.

So, we're going around and around in circles here because you're
repeatedly refusing to explain how the slave will know WHEN to send
acknowledgments back to the master without knowing which sync rep
level is in use.  It seems to be perfectly evident to everyone else
here that there are only two ways for this to work: either the value
is configured on the standby, or there's a registration system on the
master and the master tells the standby its wishes.  Instead of asking
the entire community to wait for an unspecified period of time for you
to write code that will handle this in an unspecified way, how about
answering the question?  We've wasted far too much time arguing about
this already.

Robert Haas
The Enterprise Postgres Company

In response to


pgsql-hackers by date

Next:From: David E. WheelerDate: 2010-09-07 16:24:27
Subject: function_name.parameter_name
Previous:From: Teodor SigaevDate: 2010-09-07 16:02:11
Subject: Re: gincostestimate

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