From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: autovauum integration patch: Attempt #4 |
Date: | 2004-08-03 01:53:57 |
Message-ID: | 17611.1091498037@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-08-03 01:58:45 | Re: autovauum integration patch: Attempt #4 |
Previous Message | Bruce Momjian | 2004-08-03 01:36:07 | Re: autovauum integration patch: Attempt #4 |