public inbox for [email protected]  

help / color / mirror / Atom feed

From: Fujii Masao <[email protected]>
To: Masahiko Sawada <[email protected]>
To: Andres Freund <[email protected]>
Cc: [email protected]
Cc: Fujii Masao <[email protected]>
Subject: Re: Logging in LockBufferForCleanup()
Date: Fri, 11 Feb 2022 00:47:50 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAD21AoCdm0dTgU-JJTgPu7tN-8_8LXzNVraNc8Lg-zC5qHNBiQ@mail.gmail.com>
References: <[email protected]>
	<CAD21AoCdm0dTgU-JJTgPu7tN-8_8LXzNVraNc8Lg-zC5qHNBiQ@mail.gmail.com>



On 2022/02/10 20:28, Masahiko Sawada wrote:
> While I understand that these are theoretically valid concerns, it’s
> unclear to me how much the current code leads to bad effects in
> practice. There are other low-level codes/paths that call palloc()
> while holding LWLocks, and I’m not sure that the overheads result in
> visible negative performance impact particularly because the calling
> to LockBufferForCleanup() is likely to accompany wait in the first
> place.

I'm also not sure that. palloc() for PS display, copy of process title, GetCurrentTimestamp() and ereport() of recovery conflict happen when we fail to acquire the lock. In this case we also call ResolveRecoveryConflictWithBufferPin() and wait to be signaled there. So compared to the wait time or overhead caused in ResolveRecoveryConflictWithBufferPin(), ISTM that the overhead caused by them would be ralatively small. Also ereport() of recovery conflict can happen only when log_recovery_conflict_waits parameter is enabled and the deadlock timeout happens during the lock wait.


> BTW I think calling to LockBufferForCleanup() in a critical
> section is a bad idea for sure since it becomes uninterruptible.

Yes. And as far as I tested, currently LockBufferForCleanup() is not called in critical section. Right?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

view thread (3+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Logging in LockBufferForCleanup()
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox