Re: max_wal_senders must die

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> One idea I've had is that we might want to think about defining an
> operation that is effectively "store, with a memory barrier". For
> example, on x86, this could be implemented using xchg. I think if you
> have a single-word variable in shared memory that is always updated
> using a locked store, then individual backends should be able to read
> it unlocked without risk of seeing a stale value.

You're still guilty of fuzzy thinking here. What does "stale" mean?
To do anything useful, you need to be able to fetch the value, execute
some sequence of operations that depends on the value, and be assured
that the value you fetched remains relevant throughout that sequence.
A memory barrier by itself doesn't help.

I have seen one or two places where we could use a memory barrier
primitive that doesn't include a lock, but they had to do with ensuring
that different writes would be seen to have occurred in a particular
order. It is not obvious how we could use one here.

Now, one could also argue that commit is already a sufficiently
heavyweight operation that taking/releasing one more LWLock won't
matter too much. But it would be nice to back that argument with
some evidence.

> Come to think of it, I'm not really sure I understand what protects
> SetLatch() against memory ordering hazards. Is that actually safe?

Hmm ... that's a good question. It certainly *looks* like it could
malfunction on machines with weak memory ordering.

regards, tom lane