Why do we keep UnusedLock1 in LWLockId?

Started by ITAGAKI Takahiroalmost 17 years ago2 messages
#1ITAGAKI Takahiro
itagaki.takahiro@oss.ntt.co.jp

Hi,

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.

Are there any reason to keep UnusedLock1 there?
Or can we remove it simpley?

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

#2Heikki Linnakangas
heikki.linnakangas@enterprisedb.com
In reply to: ITAGAKI Takahiro (#1)
Re: Why do we keep UnusedLock1 in LWLockId?

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