Re: BUG #14231: logical replication wal sender process spins when using error traps in function

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14231: logical replication wal sender process spins when using error traps in function
Date: 2016-07-13 18:49:24
Message-ID: CAM3SWZQFGiqi=B_Rs7QFwzzTyAMH8FC_7qE6ATWjSLNCfeooKQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Jul 13, 2016 at 11:36 AM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>> 0011c0091e886b874e485a46ff2c94222ffbf550. This allowed tuplesort.c to
>> blow away the free list via a new call to MemoryContextReset(). This
>> didn't even remove *any* pfree() operations in the affected codepath,
>> but was still quite effective.
>>
>> I'm not sure that that's comparable, but it may be an interesting case
>> that others are not aware of.
>>
>
> I'm not very familiar with the reorderbuffer.c, but my understanding is that
> it's an object with potentially very long lifetime, doing a lot of
> interleaved palloc/pfree (or accessing the slab cache). The lifetime of
> tuplesort is much shorter with clear boundaries, and probably does not need
> palloc/pfree interleaved that much.

Actually, the lifetime of a non-final merge step could be tens of
seconds or more, and there are continual palloc() and pfree() calls at
the tuple level, which leads to this fragmentation. (Note that this
does apply to final on-the-fly merges, which were made to use batch
memory by that same commit.)

--
Peter Geoghegan

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message wayne.warren 2016-07-14 13:27:44 BUG #14249: In FDW, variable not found in subplan target list
Previous Message Tomas Vondra 2016-07-13 18:36:56 Re: BUG #14231: logical replication wal sender process spins when using error traps in function