Re: Add parallelism and glibc dependent only options to reindexdb
От | Alvaro Herrera |
---|---|
Тема | Re: Add parallelism and glibc dependent only options to reindexdb |
Дата | |
Msg-id | 20190722170532.GA26019@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Add parallelism and glibc dependent only options to reindexdb (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add parallelism and glibc dependent only options to reindexdb
|
Список | pgsql-hackers |
On 2019-Jul-22, Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > On 2019-Jul-22, Julien Rouhaud wrote: > >> On Mon, Jul 22, 2019 at 5:11 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > >>> Can we use List for this instead? > > >> Isn't that for backend code only? > > > Well, we already have palloc() on the frontend side, and list.c doesn't > > have any elog()/ereport(), so it should be possible to use it ... I do > > see that it uses MemoryContextAlloc() in a few places. Maybe we can > > just #define that to palloc()? > > I'm not happy about either the idea of pulling all of list.c into > frontend programs, or restricting it to be frontend-safe. That's > very fundamental infrastructure and I don't want it laboring under > such a restriction. Furthermore, List usage generally leaks memory > like mad (cf nearby list_concat discussion) which doesn't seem like > something we want for frontend code. Fair enough. List has gotten quite sophisticated now, so I understand the concern. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: