From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: strange perf regression with data checksums |
Date: | 2025-05-21 16:29:11 |
Message-ID: | lbt2lqnbh5thcamt5zxpolmu35wg3coa5i523gpvqip3bsj7gw@4s4n4upizbo4 |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2025-05-19 15:45:01 -0400, Peter Geoghegan wrote:
> On Mon, May 19, 2025 at 3:37 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I think we can do better - something like
> >
> > #ifdef PG_HAVE_8BYTE_SINGLE_COPY_ATOMICITY
> > lsn = PageGetLSN(page);
> > #else
> > buf_state = LockBufHdr(bufHdr);
> > lsn = PageGetLSN(page);
> > UnlockBufHdr(bufHdr, buf_state);
> > #endif
> >
> > All perf relevant systems support reading 8 bytes without a chance of
> > tearing...
>
> Even assuming that this scheme works perfectly, I'd still like to
> pursue the idea I had about fixing this in nbtree.
>
> The relevant nbtree code seems more elegant if we avoid calling
> BufferGetLSNAtomic() unless and until its return value might actually
> be useful. It's quite a lot easier to understand the true purpose of
> so->currPos.lsn with this new structure.
I'm not against that - ISTM we should do both.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2025-05-21 16:55:22 | Re: Avoid orphaned objects dependencies, take 3 |
Previous Message | Paul A Jungwirth | 2025-05-21 16:28:07 | Re: SQL:2011 application time |