Re: autovauum integration patch: Attempt #4 - Mailing list pgsql-patches

From Tom Lane
Subject Re: autovauum integration patch: Attempt #4
Date
Msg-id 17611.1091498037@sss.pgh.pa.us
Whole thread Raw
In response to Re: autovauum integration patch: Attempt #4  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: autovauum integration patch: Attempt #4  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: autovauum integration patch: Attempt #4  ("Matthew T. O'Connor" <matthew@zeut.net>)
List pgsql-patches
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.

> 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.

            regards, tom lane

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: autovauum integration patch: Attempt #4
Next
From: Bruce Momjian
Date:
Subject: Re: autovauum integration patch: Attempt #4