From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: autovacuum launcher using InitPostgres |
Date: | 2009-08-31 21:42:16 |
Message-ID: | m21vmr64p3.fsf@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> The user may not care about the difference, but there's a point in
>> having the limit be the simpler concept of "this is the maximum amount
>> of processes running vacuum at any time". The launcher is very
>> uninteresting to users.
Adding to this, the launcher will not consume maintenance_work_mem
whereas each worker is able to allocate that much, IIUC.
> I committed things that way, but I'm still not convinced that we
> shouldn't expose the launcher in pg_stat_activity. The thing that
> is bothering me is that it is now able to take locks and potentially
> could block some other process or even participate in a deadlock.
> Do we really want to have entries in pg_locks that don't match any
> entry in pg_stat_activity?
Having the launcher locks show as such gets my vote too, but then I'm
following on your opinion that a launcher ain't a worker and that users
need to know about it.
Let's keep the autovacuum_max_workers GUC naming, not counting the
"there can be only one" launcher so that we're able to size
maintenance_work_mem.
Regards,
--
dim
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2009-08-31 21:47:21 | Re: 8.5 release timetable, again |
Previous Message | Alvaro Herrera | 2009-08-31 21:00:20 | Re: [PATCH] Largeobject access controls |