Re: Reducing walreceiver latency with a latch
От | Heikki Linnakangas |
---|---|
Тема | Re: Reducing walreceiver latency with a latch |
Дата | |
Msg-id | 4C8E10E1.2070104@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Reducing walreceiver latency with a latch (Thom Brown <thom@linux.com>) |
Ответы |
Re: Reducing walreceiver latency with a latch
|
Список | pgsql-hackers |
On 13/09/10 14:47, Thom Brown wrote: > On 13 September 2010 12:40, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: >> Now that we have the wonderful latch facility, let's use it to reduce the >> delay between receiving a piece of WAL and applying in the standby. >> Currently, the startup process polls every 100ms to see if new WAL has >> arrived, which adds an average a 50 ms delay between a transaction commit in >> the master and it appearing as committed in a hot standby server. The latch >> patch eliminated a similar polling delay in walsender already, the attached >> patch does the same for walreceiver. >> >> After this patch, there is no unnecessary delays in the streaming >> replication code path. Note that this is all still asynchronous, just with >> reduced latency. >> >> This is pretty straightforward, but any comments? > > Is that supposed to be waiting 5000ms? Yes, it gets interrupted as soon as WAL arrives, that timeout is to poll for the standby trigger file to appear or SIGTERM. BTW, I noticed that I missed incrementing the latch count in win32_latch.c, and the owning/disowning the latch was done correctly, you get an error if you restart the master and reconnect. I'll post an updated patch shortly. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: