| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Fujii Masao <fujii(at)postgresql(dot)org> |
| Subject: | Re: Logging in LockBufferForCleanup() |
| Date: | 2022-02-10 02:43:32 |
| Message-ID: | YgR71JCHgg6WCC09@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2022-02-10 02:47:09 | Re: catalog access with reset GUCs during parallel worker startup |
| Previous Message | Michael Paquier | 2022-02-10 02:38:44 | Re: Possible uninitialized use of the variables (src/backend/access/transam/twophase.c) |