Re: Walsender timeouts and large transactions

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
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

In response to

Responses

Browse pgsql-hackers by date

  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