[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] autovacuum launcher using InitPostgres
From:       Dimitri Fontaine <dfontaine () hi-media ! com>
Date:       2009-08-31 21:42:16
Message-ID: m21vmr64p3.fsf () hi-media ! com
[Download RAW message or body]

Hi,

Tom Lane <tgl@sss.pgh.pa.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic