Re: BUG #14231: logical replication wal sender process spins when using error traps in function
От | Peter Geoghegan |
---|---|
Тема | Re: BUG #14231: logical replication wal sender process spins when using error traps in function |
Дата | |
Msg-id | CAM3SWZQFGiqi=B_Rs7QFwzzTyAMH8FC_7qE6ATWjSLNCfeooKQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #14231: logical replication wal sender process spins when using error traps in function (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Список | pgsql-bugs |
On Wed, Jul 13, 2016 at 11:36 AM, Tomas Vondra <tomas.vondra@2ndquadrant.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
В списке pgsql-bugs по дате отправления: