On 13/09/10 14:47, Thom Brown wrote:
On 13 September 2010 12:40, Heikki Linnakangas
<heikki.linnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
