Re: autovauum integration patch: Attempt #4
От | Tom Lane |
---|---|
Тема | Re: autovauum integration patch: Attempt #4 |
Дата | |
Msg-id | 17611.1091498037@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: autovauum integration patch: Attempt #4 (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: autovauum integration patch: Attempt #4
Re: autovauum integration patch: Attempt #4 |
Список | 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 по дате отправления: