Re: Hot Standby on git - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Hot Standby on git
Date
Msg-id 4ACA6EDE.4020407@enterprisedb.com
Whole thread Raw
In response to Re: Hot Standby on git  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Hot Standby on git  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs wrote:
> We discussed briefly your change 
> 0011-Replace-per-proc-counters-of-loggable-locks-with-per.patch.
> 
> I don't see how that helps at all. The objective of lock counters was to
> know if we can skip acquiring an LWlock on all lock partitions. This
> change keeps the lock counters yet acquires the locks we were trying to
> avoid. This change needs some justification since it is not a bug fix.

Well, the original code was buggy. But more to the point, it's a lot
simpler this way, I don't see any reason why the counters should be
per-process, meaning that they need to be exposed in the pgproc structs
or procarray.c.

The point is to avoid the seqscan of the lock hash table. I presumed
that's the expensive part in GetRunningTransactionLocks().

Tom Lane wrote:
> [ scratches head ... ]  Why is hot standby messing with this sort of
> thing at all?  It sounds like a performance optimization that should
> be considered separately, and *later*.

Yeah, I too considered just ripping it out. Simon is worried that
locking all the lock partitions and scanning the locks table can take a
long time. We do that in the master, while holding both ProcArrayLock
and XidGenLock in exclusive mode (hmm, why is shared not enough?), so
there is some grounds for worry. OTOH, it's only done once per checkpoint.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [PATCH] Reworks for Access Control facilities (r2311)
Next
From: Heikki Linnakangas
Date:
Subject: Re: Hot Standby on git