Isn't non-TEST_AND_SET code long dead?

I was bemused to notice this afternoon that the backend does not build
if you have not defined HAVE_TEST_AND_SET; furthermore, this has been
true at least since 6.4. (slock() is compiled anyway, and it calls
TAS(), which will be an undefined symbol.) From the lack of
complaints we can deduce that no one has run Postgres on a
non-TEST_AND_SET platform in quite a while.

Kinda makes me wonder what other bit-rot has set in in the non-TAS
code, and whether we ought not just rip it out rather than try to
"maintain" exceedingly delicate code that's gone untested for years.
bufmgr.c, in particular, has behavior that's nontrivially different
when HAVE_TEST_AND_SET isn't defined --- who wants to promise that
that still works?

regards, tom lane

Yank her ...

On Sat, 2 Sep 2000, Tom Lane wrote:

> I was bemused to notice this afternoon that the backend does not build
> if you have not defined HAVE_TEST_AND_SET; furthermore, this has been
> true at least since 6.4. (slock() is compiled anyway, and it calls
> TAS(), which will be an undefined symbol.) From the lack of
> complaints we can deduce that no one has run Postgres on a
> non-TEST_AND_SET platform in quite a while.
>
> Kinda makes me wonder what other bit-rot has set in in the non-TAS
> code, and whether we ought not just rip it out rather than try to
> "maintain" exceedingly delicate code that's gone untested for years.
> bufmgr.c, in particular, has behavior that's nontrivially different
> when HAVE_TEST_AND_SET isn't defined --- who wants to promise that
> that still works?
>
> regards, tom lane
>

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org

The Hermit Hacker wrote:
>
> Yank her ...
>
> On Sat, 2 Sep 2000, Tom Lane wrote:
> > Kinda makes me wonder what other bit-rot has set in in the non-TAS
> > code, and whether we ought not just rip it out rather than try to
> > "maintain" exceedingly delicate code that's gone untested for years.
> > bufmgr.c, in particular, has behavior that's nontrivially different
> > when HAVE_TEST_AND_SET isn't defined --- who wants to promise that
> > that still works?
> >
> > regards, tom lane
> >

On a somewhat related note, what about the NO_SECURITY defines
strewn throughout the backend? Does anyone run the server with
NO_SECURITY defined? And if so, what benefit is that over just
running with everything owned by the same user?

Just curious,

Mike Mascari

Mike Mascari <mascarm(at)mascari(dot)com> writes:
> On a somewhat related note, what about the NO_SECURITY defines
> strewn throughout the backend? Does anyone run the server with
> NO_SECURITY defined? And if so, what benefit is that over just
> running with everything owned by the same user?

I suppose the idea was to avoid expending *any* cycles on security
checks if you didn't need them in your particular situation. But
offhand I've never heard of anyone actually using the feature. I'm
dubious whether the amount of time saved would be worth the trouble.

regards, tom lane

> Mike Mascari <mascarm(at)mascari(dot)com> writes:
> > On a somewhat related note, what about the NO_SECURITY defines
> > strewn throughout the backend? Does anyone run the server with
> > NO_SECURITY defined? And if so, what benefit is that over just
> > running with everything owned by the same user?
>
> I suppose the idea was to avoid expending *any* cycles on security
> checks if you didn't need them in your particular situation. But
> offhand I've never heard of anyone actually using the feature. I'm
> dubious whether the amount of time saved would be worth the trouble.

NO_SECURITY define removed.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026