Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
