| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, blake(at)rcmail(dot)com, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, Andres Freund <andres(at)anazarel(dot)de> |
| Subject: | Re: BUG #14231: logical replication wal sender process spins when using error traps in function |
| Date: | 2016-07-06 21:40:02 |
| Message-ID: | CAM3SWZSqBWmJEwu6-aFkN7XkPdybw_nrSfcjNtnJvq8m8-Rcig@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Jul 6, 2016 at 2:26 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>> So I think this is primarily an artifact of doing so much retail
>> palloc/pfree in a single memory context.
>
> As I recall, this is the main reason Andres stuck the slab cache in
> reorderbuffer. Maybe it'd be worthwhile to implement a different
> MemoryContext tailored to this use case, and remove the slab cache
> stuff.
I withdraw my remarks on that commit -- I don't think that's what it is now.
I had luck adding a new child memory context for tuplesort.c in commit
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.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2016-07-06 21:40:24 | Re: BUG #14150: Attempted to delete invisible tuple |
| Previous Message | Andres Freund | 2016-07-06 21:38:28 | Re: BUG #14231: logical replication wal sender process spins when using error traps in function |