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.

> 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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Reply via email to