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.na...@bluetreble.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
