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 →
-
Remove traces of support for Sun Studio compiler
- 25f36066dd2a 19 (unreleased) cited
-
Further tidy-up for old CPU architectures.
- 718aa43a4ee6 16.0 cited
-
Implement new 'lightweight lock manager' that's intermediate between
- 499abb0c0f21 7.2.1 cited
-
Fix failure in CreateCheckPoint on some Alpha boxes --- it's not OK to
- 7f60b81e1ab7 7.1.1 cited
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