On Wed, Jan 31, 2024 at 3:01 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > > Looking at 0003, where an XXX comment is added about taking a spinlock > to read LogwrtResult, I suspect the answer is probably not, because it > is likely to slow down the other uses of LogwrtResult.
We avoided keeping LogwrtResult latest as the current callers for WALReadFromBuffers() all determine the flush LSN using GetFlushRecPtr(), see comment #4 from https://www.postgresql.org/message-id/CALj2ACV%3DC1GZT9XQRm4iN1NV1T%3DhLA_hsGWNx2Y5-G%2BmSwdhNg%40mail.gmail.com. > But I wonder if > a better path forward would be to base further work on my older > uncommitted patch to make LogwrtResult use atomics. With that, you > wouldn't have to block others in order to read the value. I last posted > that patch in [1] in case you're curious. > > [1] https://postgr.es/m/20220728065920.oleu2jzsatchakfj@alvherre.pgsql > > The reason I abandoned that patch is that the performance problem that I > was fixing no longer existed -- it was fixed in a different way. Nice. I'll respond in that thread. FWIW, there's been a recent attempt at turning unloggedLSN to 64-bit atomic - https://commitfest.postgresql.org/46/4330/ and that might need pg_atomic_monotonic_advance_u64. I guess we would have to bring your patch and the unloggedLSN into a single thread to have a better discussion. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com