Alvaro Herrera <alvherre@atentus.com> writes:
>>> It seems to me I'll have to add some amount of lock types
>>> in the lock manager. Does that bother you?
>>
>> Such as?
> There are three new lock modes: R, RX and RS (Reorganizer, Reorganizer
> Exclusive and Reorganizer Shared). Actually, they are not new lock
> types; rather, new objects on which locks should be obtained before
> using the index pages.
We've got a ton of lock modes already; perhaps these operations can be
mapped into acquiring some existing lock modes on index pages?
Note that there is currently a notion of using exclusive lock on page
zero of a relation (either index or heap) to interlock extension of the
relation. You can probably change that or work around it if you want to
assign other semantics to locking index pages; just be aware that it's
out there.
> But there's some work to do before that. I need to make the nbtree code
> actually use its free page list. That is, new pages for splits should
> be taken from the free page, or a new page should be created if there
> are none; also, deleting the last element from a page should put it into the
> free page list. I'm looking at that code now. Let me know if you think
> there's something I should know about this.
Yeah, you can't recycle pages without a freelist :-(. One thing that
bothered me about that was that adding/removing freelist pages appears
to require exclusive lock on the index metapage, which would
unnecessarily block many other index operations. You should try to
structure things to avoid that. Maybe the freelist head link can be
treated as a separately lockable object.
Don't forget to think about WAL logging of these operations.
regards, tom lane