| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Remove SpinLockFree() / S_LOCK_FREE()? |
| Date: | 2020-06-08 23:00:26 |
| Message-ID: | 2112089.1591657226@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-06-09 00:11:43 | Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan |
| Previous Message | Andres Freund | 2020-06-08 22:53:38 | Remove SpinLockFree() / S_LOCK_FREE()? |