Re: Logging in LockBufferForCleanup() - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Logging in LockBufferForCleanup()
Date
Msg-id YgR71JCHgg6WCC09@paquier.xyz
Whole thread Raw
In response to Logging in LockBufferForCleanup()  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Wed, Feb 09, 2022 at 06:22:05PM -0800, Andres Freund wrote:
> Previously the code looked somewhat safe to use in critical section like
> blocks (although whether it'd be good idea to use in one is a different
> question), but not after. Even if not used in a critical section, adding new
> failure conditions to low-level code that's holding LWLocks etc. doesn't seem
> like a good idea.

This is an interesting point.  Would the addition of one or more
critical sections in this area impact its performance in any way?

> It also just increases the overhead of LockBuffer(). Adding palloc(), copying
> of process title, GetCurrentTimestamp() to a low level routine like this isn't
> free - even if it's mostly in the contended paths.

Good point.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Possible uninitialized use of the variables (src/backend/access/transam/twophase.c)
Next
From: Robert Haas
Date:
Subject: Re: catalog access with reset GUCs during parallel worker startup