On Sat, Mar 8, 2025 at 7:21 AM Andres Freund wrote:
>
> FWIW, I am fairly certain that any non-toy algorithm that requires a full
> memory barrier instead of just an acquire in case of a CAS failure is chock
> full of concurrency bugs.
Yeah -- off the top of my head, I can think of only two CAS p
Hi,
On 2025-03-08 17:06:38 +0200, Alexander Korotkov wrote:
> On Sat, Mar 8, 2025 at 3:41 PM Andres Freund wrote:
> >
> > On 2025-03-08 08:02:41 -0500, Andres Freund wrote:
> > > From the C/C++ standard atomics model it doesn't make sense to say that a
> > > failed CAS has release semantics, as t
On Sat, Mar 8, 2025 at 3:41 PM Andres Freund wrote:
>
> On 2025-03-08 08:02:41 -0500, Andres Freund wrote:
> > From the C/C++ standard atomics model it doesn't make sense to say that a
> > failed CAS has release semantics, as there simply isn't a write that could
> > be
> > ordered! What their b
Hi,
On 2025-03-08 08:02:41 -0500, Andres Freund wrote:
> From the C/C++ standard atomics model it doesn't make sense to say that a
> failed CAS has release semantics, as there simply isn't a write that could be
> ordered! What their barriers guarantee is ordering between multiple memory
> operati
Hi,
On 2025-03-08 14:12:13 +0200, Alexander Korotkov wrote:
> I'm not an expert in formal specifications of memory models. But I'm quite
> surprised we're discussing whether memory barrier on compare-exchange
> failure might matter. For me at least the fact
> that __atomic_compare_exchange_n() h
Hi, Andres!
On Fri, Mar 7, 2025 at 7:54 PM Alexander Korotkov
wrote:
> On Fri, Mar 7, 2025 at 7:46 PM Andres Freund wrote:
> > On 2025-03-07 19:44:20 +0200, Alexander Korotkov wrote:
> > > On Fri, Mar 7, 2025 at 7:38 PM Andres Freund
wrote:
> > > > On 2025-03-07 19:15:23 +0200, Alexander Korotk
On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> On 2025-03-07 18:39:42 +0200, Alexander Korotkov wrote:
> > On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
> > >
> > > On 2025-03-07 17:47:08 +0200, Alexander Korotkov wrote:
> > > > While investigating a bug in the patch to get rid of WA
On Fri, Mar 7, 2025 at 7:46 PM Andres Freund wrote:
> On 2025-03-07 19:44:20 +0200, Alexander Korotkov wrote:
> > On Fri, Mar 7, 2025 at 7:38 PM Andres Freund wrote:
> > > On 2025-03-07 19:15:23 +0200, Alexander Korotkov wrote:
> > > > On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> > > >
On Fri, Mar 7, 2025 at 7:38 PM Andres Freund wrote:
> On 2025-03-07 19:15:23 +0200, Alexander Korotkov wrote:
> > On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> > > What is the access pattern and the observed problems with it that made you
> > > look at the disassembly?
> >
> > Check this
On 2025-03-07 19:44:20 +0200, Alexander Korotkov wrote:
> On Fri, Mar 7, 2025 at 7:38 PM Andres Freund wrote:
> > On 2025-03-07 19:15:23 +0200, Alexander Korotkov wrote:
> > > On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> > > > What is the access pattern and the observed problems with it
Hi,
On 2025-03-07 19:15:23 +0200, Alexander Korotkov wrote:
> On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> > What is the access pattern and the observed problems with it that made you
> > look at the disassembly?
>
> Check this code.
>
> l1: pg_atomic_write_u64(&XLogCtl->xlblocks[n
Hi,
On 2025-03-07 21:08:34 +0400, Pavel Borisov wrote:
> On Fri, 7 Mar 2025 at 20:40, Alexander Korotkov wrote:
> > Yes, there surely should be a memory barrier on another side. But
> > does __ATOMIC_SEQ_CST works as a barrier for the regular read/write
> > operations on the same side?
> Accordi
On Fri, Mar 7, 2025 at 7:15 PM Alexander Korotkov wrote:
>
> On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> > On 2025-03-07 18:39:42 +0200, Alexander Korotkov wrote:
> > > On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
> > > >
> > > > On 2025-03-07 17:47:08 +0200, Alexander Korotkov
On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> On 2025-03-07 18:39:42 +0200, Alexander Korotkov wrote:
> > On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
> > >
> > > On 2025-03-07 17:47:08 +0200, Alexander Korotkov wrote:
> > > > While investigating a bug in the patch to get rid of
WA
Hi, Alexander and Andres!
On Fri, 7 Mar 2025 at 20:40, Alexander Korotkov wrote:
>
> Hi, Andres.
>
> Thank you for reply.
>
> On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
> >
> > On 2025-03-07 17:47:08 +0200, Alexander Korotkov wrote:
> > > While investigating a bug in the patch to get ri
Hi,
On 2025-03-07 18:39:42 +0200, Alexander Korotkov wrote:
> On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
> >
> > On 2025-03-07 17:47:08 +0200, Alexander Korotkov wrote:
> > > While investigating a bug in the patch to get rid of WALBufMappingLock, I
> > > found that the surrounding pg_ato
Hi, Andres.
Thank you for reply.
On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
>
> On 2025-03-07 17:47:08 +0200, Alexander Korotkov wrote:
> > While investigating a bug in the patch to get rid of WALBufMappingLock, I
> > found that the surrounding pg_atomic_compare_exchange_u64() fixes the
Hi,
On 2025-03-07 17:47:08 +0200, Alexander Korotkov wrote:
> While investigating a bug in the patch to get rid of WALBufMappingLock, I
> found that the surrounding pg_atomic_compare_exchange_u64() fixes the
> problem for me.
That sounds more likely to be due to slowing down things enough to make
Hi all,
While investigating a bug in the patch to get rid of WALBufMappingLock, I
found that the surrounding pg_atomic_compare_exchange_u64() fixes the
problem for me. That doesn't feel right because, according to the
comments, both pg_atomic_compare_exchange_u32() and
pg_atomic_compare_exchange_
19 matches
Mail list logo
