Re: WIP: Access method extendability

On 2014-10-29 14:33:00 -0500, Jim Nasby wrote:
> On 10/28/14, 3:27 PM, Simon Riggs wrote:
> >On 28 October 2014 17:50, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> >>On 10/28/14, 9:22 AM, Simon Riggs wrote:
> >>>
> >>>2. Some additional code in Autovacuum to rebuild corrupt indexes at
> >>>startup, using AV worker processes to perform a REINDEX CONCURRENTLY.
> >>
> >>
> >>I don't think loading more functionality into autovac is the right way to do
> >>that.
> >
> >You'd need to explain why and/or suggest your right way.
>
> Why wouldn't we register it as a background worker?
>
> Not only doesn't this have anything to do with vacuum, but it should operate differently as well: once we've rebuilt everything that needs to be rebuilt the process should go away until the next startup. That's the opposite of what autovac does.

That's pretty much how autovac workers work. Do stuff until not needed
anymore. The difference is that you have a process that starts them.

It'd not be a good idea to throw this together with user defined
bgworkers because there's a finite number of slots for them. So at the
very least we'd need a separate pool for system bgworkers. Which would
persistently take up resources (PGPROC entries et al). So it seems
better to use the existing pool of autovac workers.

> The one potential commonality I see is having a launcher process that's responsible for launching multiple workers (if we want to be rebuilding multiple indexes at once), but AFAICT that capability is also provided by bgworker.c.

There really is no need to use bgworkers for builtin things. They are
useful because they allow extensions to do what in core already could do
for a long time.

Greetings,

Andres Freund

PS: You mails would be easier to read if htey had sane line lenghts...

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services