From: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org, andres(at)anarazel(dot)de |
Subject: | Re: Walsender timeouts and large transactions |
Date: | 2017-06-25 11:38:20 |
Message-ID: | cb3d5ccd-de0e-c29d-0b1f-7e38142d0df3@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30/05/17 15:44, Petr Jelinek wrote:
> On 30/05/17 11:02, Kyotaro HORIGUCHI wrote:
>>
>> + TimestampTz now = GetCurrentTimestamp();
>>
>> I think it is not recommended to read the current time too
>> frequently, especially within a loop that hates slowness. (I
>> suppose that a loop that can fill up a send queue falls into that
>
> Yeah that was my main worry for the patch as well, although given that
> the loop does tuple processing it might not be very noticeable.
>
I realized we actually call GetCurrentTimestamp() there anyway (for the
pq_sendint64). So I just modified the patch to use the now variable
there instead which means there are no additional GetCurrentTimestamp()
calls compared to state before patch now.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Fix-walsender-timeouts-when-decoding-large-transacti.patch | text/x-patch | 3.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-06-25 15:45:28 | CREATE COLLATION definitional questions for ICU |
Previous Message | Petr Jelinek | 2017-06-25 11:00:51 | Re: Logical replication: stuck spinlock at ReplicationSlotRelease |