Re: small cleanup for s_lock.h

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2026-05-04T22:16:47Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove traces of support for Sun Studio compiler

  2. Further tidy-up for old CPU architectures.

  3. Implement new 'lightweight lock manager' that's intermediate between

  4. Fix failure in CreateCheckPoint on some Alpha boxes --- it's not OK to

Nathan Bossart <nathandbossart@gmail.com> writes:
> I noticed that s_lock.h points to a default implementation of tas() in
> tas.s or s_lock.c, but AFAICT there hasn't been a tas() implementation in
> s_lock.c since commit 718aa43a4e, and commit 25f36066dd seems to have
> removed the last remaining tas.s files.  So, I think this is dead code.

It is, but I think the 0001 patch should be more like

 #if !defined(TAS)
-extern int	tas(volatile slock_t *lock);		/* in port/.../tas.s, or
-							 * s_lock.c */
-
-#define TAS(lock)		tas(lock)
+#error "must provide a spinlock implementation"
 #endif	 /* TAS */

Perhaps this could be merged with the earlier bit about erroring
if not HAS_TEST_AND_SET.

> I also noticed that HAS_TEST_AND_SET just means that TAS is defined, so I
> wrote a 0002 that removes it in favor of checking TAS directly.

I'm pretty much -1 on that; HAS_TEST_AND_SET is clearer than TAS, and
removing it seems quite likely to break someone's code.  We could
perhaps collect all the separate instances into this end location:

#if defined(TAS)
#define HAS_TEST_AND_SET
#else
#error "must provide a spinlock implementation"
#endif	 /* TAS */

> I'd like
> to rewrite the comment at the top of the file, too, but haven't gotten to
> that yet.  I find it a little misleading, especially because we #error if
> TAS isn't defined.

No objection in principle to improving that comment, but what did you
have in mind exactly?

			regards, tom lane