Re: Streaming Replication patch for CommitFest 2009-09
От | Heikki Linnakangas |
---|---|
Тема | Re: Streaming Replication patch for CommitFest 2009-09 |
Дата | |
Msg-id | 4ABB5212.9050002@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Streaming Replication patch for CommitFest 2009-09 (Fujii Masao <masao.fujii@gmail.com>) |
Список | pgsql-hackers |
Fujii Masao wrote: > On Thu, Sep 24, 2009 at 7:41 PM, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: >> Fujii Masao wrote: >>> In the 'replication-orig' branch, walreceiver fsyncs the previous XLOG >>> file after receiving new XLOG records before writing them. This would >>> increase the backend's waiting time for replication in synchronous case. >>> The walreceiver should fsync the XLOG file after sending ACK (if needed) >>> before receiving the next XLOG records? >> I don't follow. Wareceiver does fsync the file just after writing it if >> the fsync_requested flag was set in the message. Surely that would be >> set in synchronous mode, that's what the flag is for, right? > > That's the case where fsync is issued at the end of segment. > In this case, since the fsync_requested flag is not set, > walreceiver doesn't perform fsync in that loop. After the > next XLOG arrives, walreceiver does fsync to the previous file, > in XLogWalRcvWrite(). Ok. I don't see anything wrong with that. If the primary didn't set fsync_requested, it's not in a hurry to get an acknowledgment. I guess we could check *after* writing, if we just finished filling the segment. If we did, we could fsync since we're going to fsync anyway as soon as we receive the next message. Not sure if it's worth the trouble. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: