On Mon, Nov 28, 2022 at 11:55 PM Andres Freund <andres@anarazel.de> wrote:
>
> > Is tracking lastImportantPos as pg_atomic_uint64 in XLogCtlInsert any
> > better than an explicit spinlock? I think it's better on platforms
> > where atomics are supported, however, it boils down to using a spin
> > lock on the platforms where atomics aren't supported.
>
> A central atomic in XLogCtlInsert would be better than a spinlock protected
> variable, but still bad. We do *not* want to have more central state that
> needs to be manipulated, we want *less*.
Agreed.
> If we wanted to optimize this - and I haven't seen any evidence it's worth
> doing so - we should just optimize the lock acquisitions in
> GetLastImportantRecPtr() away. *Without* centralizing the state.
Hm. I can think of converting lastImportantAt from XLogRecPtr to
pg_atomic_uint64 and letting it stay within the WALInsertLock
structure. This prevents torn-reads and also avoids WAL insertion lock
acquire-release cycles in GetLastImportantRecPtr(). Please see the
attached patch herewith.
If this idea is worth it, I would like to bring this and the other
thread [1] that converts insertingAt to atomic and modifies other WAL
insert locks related code under one roof and start a new thread. BTW,
the patch at [1] seems to be showing a good benefit for
high-concurrent inserts with small records.
Thoughts?
[1] https://www.postgresql.org/message-id/CALj2ACWkWbheFhkPwMw83CUpzHFGXSV_HXTBxG9%2B-PZ3ufHE%3DQ%40mail.gmail.com
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
