Re: Atomic rename feature for Windows.

On Wed, Apr 13, 2022 at 10:19 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Meh. I agree that it seems unlikely that anyone will come out with a
> new processor design that lacks the ability to do spinlocks or atomics.
> It's substantially more likely though that someone would want those
> configure switches temporarily while in the process of porting
> Postgres to a new processor, so that they don't have to make
> absolutely everything work before they can test anything.

It's possible. I don't think it's super-likely. If someone is
introducing a new architecture, they're probably going to make getting
the Linux kernel and gcc working on it a pretty high priority, and
they'll probably make the gcc intrinsics work, too. But you never
know. Humans are unpredictable like that.

> Independently of that, I think that our interest in weird old
> processors is mostly about checking our assumptions about exactly
> what processor-dependent facilities look like. For example,
> although I agree that spinlocks should be possible on everything
> we care about supporting, I missed the stone tablet on which it is
> graven that thou shalt use zero for the unlocked state of a spinlock.
> The main reason I keep my old HPPA dinosaur alive is because it is
> (I think) our only remaining architecture in which that isn't true,
> and I think we need to keep ourselves honest about that sort of
> detail. Next decade's hot new processor design might do things
> differently enough that it matters that we use SpinLockInit()
> not memset-to-zero. This is not academic either, as we've had
> exactly such bugs in the past.

Here again, I think it's definitely possible that that could happen,
but I don't think it's super-likely. Nobody's really implementing
spinlocks as a primitive any more; they implement atomics, and you can
decide for yourself how to build spinlocks on top of that and what
values you want to use. And if you did decide to provide spinlocks but
not atomics for some reason, you'd probably use 0 and 1 rather than 17
and 42 just because otherwise a lot of software wouldn't work on your
brand new hardware, which as a hardware manufacturer is a thing you
really don't want. We can be as rigorous as we like about this sort of
thing, but I bet that in 2022 there is a huge amount of code out that
assumes memset(...., 0, ...) is good enough. And, like, nobody's going
to be that excited about building a machine where PostgreSQL works
because we've carefully avoided this assumption, but 5000 other
software packages that haven't been as careful all break.

> The situation for OSes is a bit different, because IMV we generally
> prefer to restrict ourselves to POSIX-compliant system calls,
> and to the extent we can do that all OSes look alike. The reason
> that Windows is such a grade-A pain in the rear is exactly that
> their POSIX compliance sucks, and yet we committed to supporting
> them anyway. If some new OS that is not POSIX-compliant comes
> down the pike, I think we're far more likely to decline to support
> it than otherwise.

Yeah.

> But to tie this back to the point of the thread --- anytime we
> can reasonably start to rely on POSIX behavior in newer versions
> of Windows, I'm for that.

Sure, makes sense.

--
Robert Haas
EDB: http://www.enterprisedb.com