Re: Why do we keep UnusedLock1 in LWLockId?

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why do we keep UnusedLock1 in LWLockId?
Date: 2009-03-03 07:58:40
Message-ID: 49ACE330.9050004@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ITAGAKI Takahiro wrote:
> There is UnusedLock1 in LWLockId enumerations in storage/lwlock.h .
> | UnusedLock1, /* FreeSpaceMapLock used to be here */
>
> I thought it is for keeping LWLockId same as 8.3 at first,
> but we've already split SInvalLock to SInvalReadLock and
> SInvalWriteLock. So the IDs are changed anyway.

The idea was indeed to keep the lock numbering unchanged. Zdenek
suggested that to make dtrace scripts etc. compatible across versions.
You're right, we split SInvalLock in 8.4, so reserving the slot for
FreeSpaceLock doesn't keep the numbers unchanged. In fact, removing that
will make the rest of the lock numbers the same as in 8.3 again.

I'll remove that.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-03-03 08:04:39 Re: statistics horribly broken for row-wise comparison
Previous Message KaiGai Kohei 2009-03-03 07:39:30 Updates of SE-PostgreSQL 8.4devel patches (r1668)