Re: autovauum integration patch: Attempt #4

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > As far as libpq, can't pg_autovacuum dynamically load libpq like dblink
> > does?
>
> Hmm, make the bulk of the autovac daemon be a shlib that is dynamically
> linked by just that subprocess?  Yeah, that might work.

We certainly don't want to put any of these issues into a normal
backend.

>
> > On the password issue, can't we use .pgpass in the postgres home
> > directory?
>
> I thought of that after sending my initial email.  It's a fairly ugly
> solution, because it confuses logins/passwords that would be appropriate
> for interactive use with what you'd want the daemon to use.  But it
> might be sufficient as a stopgap.  Or possibly better, we could hack the
> autovac code to read the user and password from some protected file
> under $PGDATA.
>
> Both of these issues are things that would probably go away in the long
> run, since I doubt that we want to keep the fire-up-an-ordinary-backend
> model forever.  The thing that's troubling me at the moment is that we
> might need to spend a fair amount of work on turning what's only an
> intermediate code state into something that's usable and doesn't break
> any other stuff.  It might be better to hold off and spend that same
> work on the longer-range goal of direct integration.

Well, it is going to be a local connect so hopefully some can use
local/ident and not worry about the passswords.

The big question is how much flexibility do we have on getting this into
7.5 while still being fair to Matthew?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073