Hi, On Fri, Oct 09, 2026 at 08:54:04AM -0400, Andres Freund wrote: > Hi, > > On 2026-10-09 05:57:52 +0000, Bertrand Drouvot wrote: > > + pg_memory_barrier(); > > + > > + completions = pg_atomic_read_u64(&TransamVariables->xactCompletionCount); > > > > IIUC, the barriers order the surrounding memory accesses, but they do not > > guarantee > > that pg_atomic_read_u64() does not return an old value. > > I do not believe that that is true. Except in the sense of allowing an update > to the atomic variable having happened between pg_memory_barrier() and the > pg_atomic_read_u64(), but that's something that is indistinguishable from the > increment happening happeng just after pg_atomic_read_membarrier_u64().
Yeah, I think that you're right. BTW, this thread makes me think about your blog post [1]. I looked at the "Opportunities for further improvements" and will give this one a try: " Looking further into the future, it may very well be worthwhile to maintain efficient "running transactions with xids" data structure, instead of the current "xids of all established connections" (commonly filled largely with invalid xids). " [1]: https://techcommunity.microsoft.com/blog/adforpostgresql/improving-postgres-connection-scalability-snapshots/1806462 Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
