Re: Hot Standby on git

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot Standby on git
Date: 2009-10-05 22:10:38
Message-ID: 4ACA6EDE.4020407@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-10-05 22:30:36 Re: Hot Standby on git
Previous Message Stephen Frost 2009-10-05 21:57:34 Re: [PATCH] Reworks for Access Control facilities (r2311)