Skip site navigation (1) Skip section navigation (2)

Re: Fix spinlock usage in UnpinBuffer()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>
Cc: pgsql-patches(at)postgreSQL(dot)org
Subject: Re: Fix spinlock usage in UnpinBuffer()
Date: 2005-12-29 02:38:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
> So can you drop several lines on last post in list?

[ looks at code some more... ]  Actually, I think this code thinks that
RESUME_INTERRUPTS() will do a CHECK_FOR_INTERRUPTS() if the count drops
to zero.  Which it does not.  (Perhaps it did at one time --- I don't
recall for sure --- but it definitely doesn't now.)

Realistically, given our coding rules for spinlocks --- which pretty
nearly forbid *any* out-of-line calls while holding a spinlock, and
certainly forbid any looping --- it's probably a waste of cycles to have
the HOLD/RESUME_INTERRUPTS operations associated with spinlock
grab/release at all.  There is simply no way that any legitimate path of
control will do a CHECK_FOR_INTERRUPTS() while holding or awaiting a

So I'm thinking the right answer is to make all the spinlock macros be
the equivalent of the NoHoldoff case.  It's reasonable for LWLockAcquire
to do a HOLD_INTERRUPTS, but I don't see the justification for doing it
at the spinlock level.

> Another thing is the qsort(). Shall we change to BSD version or just let
> it be?

I'm a bit worried about doing that across-the-board, since at least in
theory a vendor-supplied qsort ought to be tuned for the hardware et al.
I think it would be better to substitute our own qsort only on those
platforms where we have specifically proved it's a win.

			regards, tom lane

In response to


pgsql-patches by date

Next:From: Michael FuhrDate: 2005-12-29 02:56:42
Subject: Extra space character in PL/pgSQL documentation
Previous:From: Qingqing ZhouDate: 2005-12-29 00:04:28
Subject: Re: Fix spinlock usage in UnpinBuffer()

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group