From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sync Rep: First Thoughts on Code |
Date: | 2008-12-23 08:22:16 |
Message-ID: | 1230020536.4793.703.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2008-12-21 at 14:46 +0900, Fujii Masao wrote:
> > XLogFlush() flushes because of an interlock between a dirty buffer write
> > and an outstanding WAL write. Dirty buffer writes are not replicated, so
> > there is no need to have a similar interlock on WAL streaming.
> >
> > So making those call points synchronous is possible, but neither
> > necessary or IMHO desirable.
>
> Yes in upcoming 8.4, but probably no in the future.
>
> What if the primary fails after writing the dirty data buffer before sending
> the corresponding logs? This would make data on the primary and logs
> on the standby inconsistent. In 8.4, such inconsistency might not matter
> because we don't use the data on the failed primary for recovery (when
> restarting the failed server, we always need a fresh backup). But, since
> this restriction is not good for some people, in the future, the failed server
> should restart without a fresh backup, and the inconsistency would be
> problem. So, I think that the inconsistency should be removed even if
> asynchronous replication case, and we should enforce "WAL rule" over
> some servers.
I don't get this argument. Why would we care what happens on the failed server?
The additional synchronizations you suggest are neither necessary, nor
IMHO desirable.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-12-23 08:56:36 | Re: encoding cleanups in cvs repo |
Previous Message | Simon Riggs | 2008-12-23 08:21:23 | Re: Hot standby and b-tree killed items |