On 03/05/2014 10:57 PM, Andres Freund wrote:
On 2014-03-05 18:26:13 +0200, Heikki Linnakangas wrote:
The logic was the same before the patch, but I added the XXX comment above.
Why do we sleep in increments of 1/10 of wal_sender_timeout? Originally, the
code calculated when the next wakeup should happen, by adding
wal_sender_timeout (or replication_timeout, as it was called back then) to
the time of the last reply. Why don't we do that?
[ archeology ]
It imo makes sense to wakeup after last_reply + wal_sender_timeout/2, so
a requested reply actually has time to arrive, but otherwise I agree.
I think your patch makes sense. Additionally imo the timeout checking
should be moved outside the if (caughtup || pq_is_send_pending()), but
that's probably a separate patch.
Any chance you could apply your patch soon? I've a patch pending that'll
surely conflict with this and it seems better to fix it first.
Ok, pushed. I left the polling-style sleep in place for now.
Thanks!
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
