| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, 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 15:54:16 |
| Message-ID: | AANLkTi=eFj3d4x69DZb=5z47sS0XA=waB0FVZz3gDWX4@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Sep 7, 2010 at 11:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
We have that problem in all of these proposals, don't we? We
certainly have no infrastructure to handle the slave getting ahead of
the master in the WAL stream.
> Also, the
> slave won't know whether it ought to fsync its own WAL before replying.
Right. And whether it ought to replay it before replying.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Markus Wanner | 2010-09-07 15:55:49 | Re: Synchronization levels in SR |
| Previous Message | Tom Lane | 2010-09-07 15:51:48 | Re: git: uh-oh |