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

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-bugs(at)postgresql(dot)org, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, blake(at)rcmail(dot)com
Subject: Re: BUG #14231: logical replication wal sender process spins when using error traps in function
Date: 2016-07-19 16:28:34
Message-ID: 37deb733-d364-1d23-3aa6-f3d88acd18f0@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 07/19/2016 06:22 PM, Tomas Vondra wrote:
>
> [one huge cup of coffee later ...]
>
> So, I think it's actually quite simple to improve this by using a
> generational design, i.e. creating a sequence of slab contexts every N
> tuples, using the average tuple length from the previous batch as input
> for the next one (multiplied by 1.5x to give a bit of slack). Maybe this
> heuristics is far too simple, but perhaps we can
>
> Attached is a v2 of the patch doing pretty much this - I wouldn't call
> this even half-baked, it's a rather early PoC thingy. But it seems to
> work, and for the test case from the initial report, it significantly
> reduces memory consumption by a factor of 100x, as the average tuple
> length is ~80B, not 8kB. It increases the runtime a bit (say, from 700ms
> to 800ms for the 100k test case), but that seems negligible compared to
> the master behavior and worth considering the memory consumption reduction.
>
> This relies on one of the SlabContext features - it can easily see which
> blocks are free because it has 'free bitmap' in each block, so old
> contexts get automatically freed once the tuples are pfreed. I have not
> made any attempt to free the context structure itself, which is a memory
> leak, but I feel lazy and it's good enough for a PoC.
>
> The AllocSet obviously can't do that, so that part is not part of the
> generation design - it would just prevent reuse of the memory, thus
> increasing memory consumption. But if we could make the AllocSet capable
> of doing AllocSetIsEmpty reasonably (and not just when it's reset, which
> is pretty useless I believe), we could discard the whole context (making
> the generational design viable).
>

Heck, we could even implement this as a special type of memory context,
suitable for cases with mostly the same palloc sizes (but not entirely
constant, as required by the SlabContext as implemented in the patch).

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2016-07-19 16:58:51 Re: BUG #14261: Hanged randomly in hash_seq_search
Previous Message Tomas Vondra 2016-07-19 16:22:13 Re: BUG #14231: logical replication wal sender process spins when using error traps in function