Re: Throwing away unnecessary spin-locks - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Throwing away unnecessary spin-locks
Date
Msg-id CAHyXU0yEAk184baUAb-K+dV3eQ2D2gkTkPRKvLrtg4zusmYQSw@mail.gmail.com
Whole thread
In response to Re: Throwing away unnecessary spin-locks  (Alexandre Felipe <o.alexandre.felipe@gmail.com>)
List pgsql-hackers
On Fri, Oct 2, 2026 at 11:02 AM Alexandre Felipe <o.alexandre.felipe@gmail.com> wrote:

Trying to find your snippet, is this the one?

yeah, there was a copy/paste error, sorry about that
 
  1262  ReserveXLogSwitch(XLogRecPtr *StartPos, XLogRecPtr *EndPos, XLogRecPtr *PrevPtr)
  1263  {
  1278          SpinLockAcquire(&Insert->insertpos_lck);
  1280          startbytepos = Insert->CurrBytePos;
  1282          ptr = XLogBytePosToEndRecPtr(startbytepos);
  1290          endbytepos = startbytepos + size;
  1303          Insert->CurrBytePos = endbytepos;
  1306          SpinLockRelease(&Insert->insertpos_lck);

This illustrates well the cases where things can't be written without a lock.
atomically. Because changes between line 1280 and line 1303 are rolled back.

However, this particular example doesn't stop us from reading because it will either
CurBytePos before line 1303, and that is the same as reading under a lock before that
block, or after the line 1303 and that is equivalent to reading under a lock after that block.

ok, sure.  This is a bit above my pay grade :-).  I guess the point is to work backward from those kinds of points, measure contention, and show the benefit.

merlin

pgsql-hackers by date:

Previous
From: Alexandre Felipe
Date:
Subject: Re: BUG #19686: Rolling back SET TABLESPACE
Next
From: Manu
Date:
Subject: Re: BUG #19686: Rolling back SET TABLESPACE