Re: Brain dump: btree collapsing

From: "Curtis Faith" <curtis(at)galtcapital(dot)com>
To: "'Curtis Faith'" <curtis(at)galtcapital(dot)com>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Hannu Krosing'" <hannu(at)tm(dot)ee>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Brain dump: btree collapsing
Date: 2003-02-14 19:25:54
Message-ID: 001001c2d45e$e5db3d00$a200a8c0@curtislaptop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I previously wrote:
> 5) A mutex/spinlock that was stored in the index could be
> acquired by the scan code like this:
>
> buf = ReadBuffer(rel, blkno); /* pin next page
> */
>
> SpinLockAcquire( indexSpecificMutex ); /* lock the index
> reorg mutex */
>
> LockBuffer(buf, BUFFER_LOCK_UNLOCK); /* release lock on
> current page */
> LockBuffer(buf, BT_READ); /* lock next page */
>
> SpinLockRelease( indexSpecificMutex ); /* unlock the index
> reorg mutex */
>
> ReleaseBuffer(buf); /* now release pin on
> previously current page */
>
> 6) The same index specific mutex/spinlock could be used for
> the merge code surrounding only the acquisition of the four
> page locks. This would obviate any problems with scans and
> page merges, since the lock acquisition for the merge could
> never occur while a scan was between pages.
>
> Further, with the reordering, the spinlock for the scan code
> doesn't seem particularly onerous since it would be
> surrounding only two LWLock calls. To reduce the overhead to
> an absolute minimum for the scan case these could be pushed
> down into a new IW call (probably necessary since the
> LockBuffer, ReleaseBuffer code does some error checking and
> such that one wouldn't want in code guarded by a mutex.

I forgot to mention that the mutex would have to be release in the event
the next page lock could not be immediately acquired just after the
addition of the scan process to the lock waiters list to avoid blocking
all scans and probably causing severe deadlock problems.

- Curtis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-02-14 19:40:09 Re: pg_dump and inserts
Previous Message Steve Crawford 2003-02-14 19:24:19 Re: location of the configuration files