Re: LogwrtResult contended spinlock - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: LogwrtResult contended spinlock
Date
Msg-id 202407011435.oiv2idunr7ps@alvherre.pgsql
Whole thread Raw
In response to Re: LogwrtResult contended spinlock  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: LogwrtResult contended spinlock
List pgsql-hackers
On 2024-Jul-01, Tom Lane wrote:

> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> >> because the failed assertion is:
> >> #ifndef PG_HAVE_ATOMIC_U64_SIMULATION
> >>     AssertPointerAlignment(&currval, 8);
> >> #endif
> 
> Perhaps this assertion is what is wrong?  If the platform has no
> native 8-byte alignment requirement, why do we think that atomics
> need it?

Oh, that's a good question.  TBH I just copied the assertion from the
other routines for 64-bit variables in the same file.  But I think
that's correct.  We're gating the assertion on _not_ having emulation,
which must mean we have native atomics; on MSVC, if I read the #ifdef
maze correctly, that's implemented using _InterlockedCompareExchange,
whose docs state:

: The variables for this function must be aligned on a 64-bit boundary;
: otherwise, this function will behave unpredictably on multiprocessor x86
: systems and any non-x86 systems. See _aligned_malloc.
https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedcompareexchange64

So I think the assertion is correct.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"[PostgreSQL] is a great group; in my opinion it is THE best open source
development communities in existence anywhere."                (Lamar Owen)



pgsql-hackers by date:

Previous
From: Stepan Neretin
Date:
Subject: Re: gamma() and lgamma() functions
Next
From: Bertrand Drouvot
Date:
Subject: Re: Surround CheckRelation[Oid]LockedByMe() with USE_ASSERT_CHECKING