On Mon, 2004-03-22 at 03:36, Gavin Sherry wrote: > One point is this: vacuum() assumes that you are running in a fully > fledged backend. There'd be a fair bit of work involved in allowing a > single process to call vacuum() against multiple databases.
I can't imagine we want to do that. > As such, I > think that a vacuum backend for a specific database should be forked upon > the first connect. Also, the backend might like to try and workout if > there are any active backends for its database every so often and if not, > perform a final vacuum (if necessary) and exit, so that we don't have lots > of idle processes sitting around. I don't understand, are you saying that upon postmaster startup a vacuum backend should be forked for every database in the cluster? > Is there a better approach than this? One thought I had is that there wouldn't be a persistent daemon type process, rather the auto_vacuum process, like the check point process, would be kicked off periodically, it would initially be attached to template1, then when it's done there it will figure out the next database to take a look at and fork, the existing template1 process will exit, and the new process will be connected to the next database, just repeat this forking loop until done. Thoughts? ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
