On 05/16/2014 04:43 PM, Andres Freund wrote:
Hi,
I don't think that's going to cut it though. The creation can take
longer than whatever wal_sender_timeout is set to (when there's lots of
longrunning transactions). I think checking whether last_reply_timestamp
= 0 during timeout checking is more robust.
Greetings,
Andres Freund
That makes sense.
A patch that does that is attached.
Steve
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
new file mode 100644
index 5c11d68..d23f06b
*** a/src/backend/replication/walsender.c
--- b/src/backend/replication/walsender.c
*************** WalSndCheckTimeOut(TimestampTz now)
*** 1738,1744 ****
timeout = TimestampTzPlusMilliseconds(last_reply_timestamp,
wal_sender_timeout);
! if (wal_sender_timeout > 0 && now >= timeout)
{
/*
* Since typically expiration of replication timeout means
--- 1738,1744 ----
timeout = TimestampTzPlusMilliseconds(last_reply_timestamp,
wal_sender_timeout);
! if (last_reply_timestamp > 0 && wal_sender_timeout > 0 && now >= timeout)
{
/*
* Since typically expiration of replication timeout means
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
