Re: Atomic rename feature for Windows.

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Apr 13, 2022 at 3:04 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> Agreed. I think that things can be usually helpful. Now, I am not
>> really convinced that there is a strong need in running a VAX if you
>> are worrying about timing issues so this is a matter of balance. You
>> could get down to the same level of coverage with something as cheap
>> as a Raspberry PI or such. There are also configure switches that
>> emulate rather non-common behaviors, like --disable-spinlocks or
>> --disable-atomics that I'd rather never see gone.

> I don't really agree with you about any of this.

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.

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.

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.

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.

regards, tom lane