Re: Remove SpinLockFree() / S_LOCK_FREE()? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Remove SpinLockFree() / S_LOCK_FREE()?
Date
Msg-id 2112089.1591657226@sss.pgh.pa.us
Whole thread Raw
In response to Remove SpinLockFree() / S_LOCK_FREE()?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> We currently have
>  *    bool SpinLockFree(slock_t *lock)
>  *        Tests if the lock is free. Returns true if free, false if locked.
>  *        This does *not* change the state of the lock.
> [ which isn't used ]
> Thus: Let's just remove SpinLockFree() / S_LOCK_FREE()?

Yeah.  I think they were included in the original design on the
theory that we'd need 'em someday.  But if we haven't found a use
yet we probably never will.  So +1 for narrowing the API a tad.

(We'd lose some error checking ability in the S_LOCK_TEST code,
but probably that's not worth worrying about.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Remove SpinLockFree() / S_LOCK_FREE()?
Next
From: Melanie Plageman
Date:
Subject: Re: Avoiding hash join batch explosions with extreme skew and weird stats