On Tue, Mar 20, 2012 at 4:35 AM, Daniel Farina <daniel@heroku.com> wrote:
> I chose the SessionId mostly because I didn't have a great sense
> around how hot the ProcArrayLock is, and it was easy to add a
> fine-grained spinlock to just get the flavor of the idea.
It's fairly hot, but terminating or canceling backends is a
sufficiently rare operation that I don't think it matters.
Terminating a large number of backends this way all at once might be
enough to create a performance hit for concurrent activities, like a
pgbench -S run that's taking snapshots at full speed. But you should
recoup that cost in a fraction of a second from the fact that there
are now many fewer backends around - even if they were idle, they
still make the ProcArray larger, and if they weren't idle, even
moreso. So I think there's no problem there that's worth sweating
over.
> To attempt to simplify your protocol more: is it necessary or sound to
> remember the PID at all if one takes a lock on the entire PGPROC
> array? At that point backend birth and death contends against that
> lock, so the postmaster just has to initialize PGPROC the usual way
> (writing over the administrative action words) and then...I don't see
> a problem, on first blush. But I'll see your midnight and raise you a
> 1:35 AM.
Well, I'm not sure it would save anything meaningful to read the PID
after releasing the lock even if it were safe, so I'd be inclined to
keep things simple. But on further reflection I had us using the PID
to find the target PGPROC in the first place, so we don't need to
"remember" a value that we already know; that step is simply
redundant.
> Also, I had a use case that would be roughly right for "cross-backend
> administration" I want to temporarily suppress autovacuum/autoanalyze
> without having to muck with thrashing configuration files, if
> possible.
ALTER TABLE can do this on a per-table basis. I think that creating a
separate way to control this on a system-wide basis would probably be
a mistake; it's rarely a good idea to have two separate systems to
manipulate the same behavior. I have often wished that we had an
ALTER SYSTEM command that could be used to make certain kinds of state
changes in lieu of having GUCs, because there are lots of things (e.g.
wal_level) that can only be changed at startup for want of the ability
to be certain that a config reload will result in everyone getting the
memo. A DDL command would have more flexibility in that regard. But
I wouldn't choose to use it for this unless it replaced, rather than
duplicated, the existing GUC.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
