Re: LogwrtResult contended spinlock - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: LogwrtResult contended spinlock
Date
Msg-id 202404071219.p5qphx7vzxte@alvherre.pgsql
Whole thread Raw
In response to Re: LogwrtResult contended spinlock  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: LogwrtResult contended spinlock
Re: LogwrtResult contended spinlock
List pgsql-hackers
I pushed the "copy" pointer now, except that I renamed it to "insert",
which is what we call the operation being tracked.  I also added some
comments.

One perhaps significant change from what Bharath submitted is that we
now use the return value from monotonic advance to return an updated
value of finishedUpto from WaitXLogInsertionsToFinish.  I think this is
a useful optimization: the only caller of WaitXLogInsertionsToFinish
which cares about its return value is XLogFlush, which AFAICS benefits
from having a more up-to-date value.

Also, I did adopt your (Jeff's) idea of using a barrier when reading
logInsertResult in WaitXLogInsertionsToFinish.  If I understand
correctly, this is actually useful: if some other CPU core was also
recently busy waiting for xlog insertions and wrote an updated version
of logInsertResult that's past what we last saw, we benefit from an
updated value because we can skip the spinlock dance and WAL-insert-var
stuff altogether.  With no barrier, we would potentially see an outdated
value of logInsertResult and waste a lot of effort to get it updated.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Those who use electric razors are infidels destined to burn in hell while
we drink from rivers of beer, download free vids and mingle with naked
well shaved babes." (http://slashdot.org/comments.pl?sid=44793&cid=4647152)



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: BitmapHeapScan streaming read user and prelim refactoring
Next
From: David Rowley
Date:
Subject: Re: Add bump memory context type and use it for tuplesorts