| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me> |
| Cc: | 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-19 19:37:14 |
| Message-ID: | z5elspkkpgxuc4hmgx2btgclpwp5wvfsak6e5fht3wmatkgwpr@ehqdvj5wgdel |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2025-05-19 18:13:02 +0200, Tomas Vondra wrote:
> I believe enabling data checksums simply makes it more severe, because
> the BufferGetLSNAtomic() has to obtain header lock, which uses the same
> "state" field, with exactly the same retry logic. It can probably happen
> even without it, but as the lock is exclusive, it also "serializes" the
> access, making the conflicts more likely.
>
> BufferGetLSNAtomic does this:
>
> bufHdr = GetBufferDescriptor(buffer - 1);
> buf_state = LockBufHdr(bufHdr);
> lsn = PageGetLSN(page);
> UnlockBufHdr(bufHdr, buf_state);
>
> AFAICS the lock is needed simply to read a consistent value from the
> page header, but maybe we could have an atomic variable with a copy of
> the LSN in the buffer descriptor?
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...
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2025-05-19 19:45:01 | Re: strange perf regression with data checksums |
| Previous Message | Vik Fearing | 2025-05-19 19:01:39 | Re: Should we optimize the `ORDER BY random() LIMIT x` case? |