On Sat, Jul 20, 2024 at 7:56 AM Andres Freund <and...@anarazel.de> wrote: > On 2024-07-19 15:36:29 -0400, Tom Lane wrote: > > Andres Freund <and...@anarazel.de> writes: > > > On 2024-07-19 11:06:47 -0400, Tom Lane wrote: > > >> 2. Do we really want to encourage people to build with -flto? > > > > > The only case I know where we do rely on compilation units providing some > > > level of boundaries is on compilers where we don't know how to emit a > > > compiler > > > barrier. That's probably a fallback we ought to remove one of these > > > days... > > > > Hm. We've moved our platform/toolchain goalposts far enough in the > > last few releases that that might not be too big a lift. Do you > > know offhand which supported platforms still have a problem there? > > > > (mumble AIX mumble) > > In 16 it looks like the only case might indeed have been [drumroll] AIX with > xlc (with gcc . And there it it looks like it'd have been trivial to implement > [1]. > > We've been talking about requiring 32 bit atomics and a spinlock > implementation - this imo fits in well with that, without proper barriers it's > pretty much impossible to have correct spinlocks and, even more so, any lock > free construct, of which we have a bunch. > > > IOW, let's rip out the fallback implementation for compiler and memory > barriers and fix the fallout, if there is any.
I'll incorporate that into the next version of: https://www.postgresql.org/message-id/flat/3351991.1697728588%40sss.pgh.pa.us ... with a view to committing in the next few days. (Ignore the <stdatomic.h> patch, that's just an experiment for now, but it's not part of what I plan to commit.)
