On Mon, 2004-08-02 at 21:53, 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.
Ok, but I will need someone else to help with this.
> > 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.
Ok, I can do this.
> 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.
I understand the concern. I'm just pushing to get autovac into 7.5, I'm
sure there are lots of people on this list who could have done a better
job, but nobody working on it...
Anyway, I'm very willing to do as much of the lifting as I can.
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend