Hi,
On 2023-01-27 18:28:16 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I'm sure we have a few places that aren't that careful, but I would hope it's
> > not a large number. Are you thinking of specific "patterns" we've repeated all
> > over, or just a few cases you recall?
>
> I recall that we used to have dependencies on, for example, the LWLock
> functions being out-of-line. Probably that specific pain point has
> been cleaned up, but it surprises me not at all to hear that there
> are more.
We did clean up a fair bit, some via "infrastructure" fixes. E.g. our
spinlocks didn't use to be a barrier a good while back (c.f. 0709b7ee72e), and
that required putting volatile on things that couldn't move across the lock
boundaries. I think that in turn was what caused the LWLock issue you
mention, as back then lwlocks used spinlocks.
The increased use of atomics instead of "let's just do a dirty read", fixed a
few instances too.
> I agree that there are probably not a huge number of places that would
> need to be fixed, but I'm not sure how we'd go about finding them.
Yea, that's the annoying part...
One thing we can look for is the use of volatile, which we used to use a lot
for preventing code rearrangement (for lack of barrier primitives in the bad
old days). Both Robert and I removed a bunch of that kind of use of volatile,
and from memory some of them wouldn't have been safe with LTO.
It's really too bad that we [have to] use volatile around signal handlers and
for PG_TRY too, otherwise it'd be easier to search for.
Kinda wondering if we ought to add a sig_volatile, err_volatile or such.
But the main thing probably is to just regularly test LTO and look for
problems. Perhaps worth adding a BF animal that uses -O3 + LTO?
I don't immediately see how to squeeze using PGO into the BF build process
(since we'd have to build without PGO, run some workload, build with PGO -
without any source modifications inbetween)...
Greetings,
Andres Freund