Re: Shared row locking - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Shared row locking
Date
Msg-id 27631.1104431813@sss.pgh.pa.us
Whole thread Raw
In response to Re: Shared row locking  (Manfred Koizar <mkoi-pg@aon.at>)
Responses Re: Shared row locking
List pgsql-hackers
Manfred Koizar <mkoi-pg@aon.at> writes:
> So the question is whether starting by making nbtree more flexible isn't
> the lower hanging fruit...

Certainly not; indexes depend on locks, not vice versa.  You'd not be
able to do that without introducing an infinite recursion into the
system design.  In any case nbtree is much more heavyweight than we need
for this --- the lock table does not want WAL support for example, nor
REINDEX/VACUUM, nor support for arbitrary index lookup conditions, nor
even multiple datatypes or multiple index columns.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: TODO item: make world safe for spaces in build/install paths
Next
From: Rémi Zara
Date:
Subject: Re: buildfarm NetBSD/m68k tsearch regression failure