Re: Sync Replication with transaction-controlled durability
От | Simon Riggs |
---|---|
Тема | Re: Sync Replication with transaction-controlled durability |
Дата | |
Msg-id | 1284553432.26910.25.camel@ebony обсуждение исходный текст |
Ответ на | Re: Sync Replication with transaction-controlled durability (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Sync Replication with transaction-controlled durability
|
Список | pgsql-hackers |
On Wed, 2010-09-15 at 11:54 +0300, Heikki Linnakangas wrote: > On 14/09/10 20:48, Simon Riggs wrote: > > When each new messages arrives from master the WALreceiver will write > > the new data to the WAL file, wake the WALwriter and then reply. Each > > new message from master receives a reply. If no further WAL data has > > been received the WALreceiver waits on the latch. If the WALReceiver is > > woken by WALWriter or Startup then it will reply to master with a > > message, even if no new WAL has been received. > > Wrt. the earlier discussion about when the standby sends the > acknowledgment, this is the key paragraph. So you *are* sending multiple > acknowledgments per transaction, but there is some smarts to combine > them when there's a lot of traffic. Fair enough. Not really. It's a simple design that works on chunks of WAL data, not individual transactions. There is literally zero code executed to achieve that, nor is bandwidth expended passing additional information. "Smarts" tends to imply some complex optimization, whereas this is the best optimization of all: no code whatsoever "per transaction". If no new WAL is received then we do two extra messages, that's all, but those replies only occur when the inbound path is otherwise quiet. In typical case of a busy system there is one reply per chunk of WAL. Since we already piggyback WAL writes into chunks in XLogWrite() that means each reply acknowledges many transactions and there are zero additional messages. Fast, efficient, no extra code. When there is only one commit in a chunk of WAL data *and* the standby is configured for 'apply' *and* nothing else occurs afterwards for some time (long enough for an fsync and an apply, so at least 10ms), there will be 3 replies for one transaction. That won't be the typical case and even when it does happen its not a problem because the server is otherwise quiet (by definition). -- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: