Re: Atomic rename feature for Windows.

Hi,

On 2022-04-13 10:19:44 -0400, Tom Lane 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.

I still think we ought to provide a compiler intrinsics spinlock
implementation for 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.

The other thing it currently has is the weird wide spinlock state where
we don't know which byte is going to be modified ... I don't think
that's likely to be needed again though.

> 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.

FWIW, I'l like to make spinlocks and atomics assert out if they've not
been initialized (which'd include preventing uninitialized use of
lwlocks). It's easy to accidentally zero out the state or start out
uninitialized. Right now nothing will complain on platforms created
after 1700 or using --disable-spinlocks --disable-atomics. That should
be caught well before running on the buildfarm...

Then the zero-state assumption wouldn't require continuing to support
HPPA.

> 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.

Our windows support is not in a great state. Part of that is that we
just plaster random hacks over issues. Which often are only needed on
windows version that nobody has access to. As you say that's different
from most of the hackiness to support some random old unix platform,
which most of the time much more localized (with the exception of not
relying on threads in some places due to old platforms).

> 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.

Yea. Same imo is true for msvc specific compiler oddities. If we can
simplify things by requiring a halfway modern msvc version, we shouldn't
hesitate.

I think it might be worth noting somewhere developer oriented that we're
ok with dropping support in HEAD for windows versions that aren't
"fully" supported anymore. Even if one can procure extended support for
a gazillion or two, they're not going to do that to run PG 19.

Greetings,

Andres Freund