Re: Add parallelism and glibc dependent only options to reindexdb
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Michael Paquier <michael@paquier.xyz>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Thomas Munro <thomas.munro@gmail.com>, Daniel Verite <daniel@manitou-mail.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Kevin Grittner <kgrittn@gmail.com>
Date: 2019-07-22T17:05:32Z
Lists: 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
Commits
-
Add support for --jobs in reindexdb
- 5ab892c391c6 13.0 landed
-
Remove more progname references in vacuumdb.c
- 3cae75f4209b 13.0 landed
-
Refactor parallelization processing code in src/bin/scripts/
- 5f3840370b63 13.0 landed