Re: [PATCH] Identify LWLocks in tracepoints

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Identify LWLocks in tracepoints
Date: 2021-03-19 20:06:40
Message-ID: 15f8bca7-1387-cc7a-e20b-8fc0b00f3669@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 18.03.21 07:34, Craig Ringer wrote:
> In patch 0001, why was the TRACE_POSTGRESQL_LWLOCK_RELEASE() call
> moved?
>   Is there some correctness issue?  If so, we should explain that (at
> least in the commit message, or as a separate patch).
>
>
> If you want I can split it out, or drop that change. I thought it was
> sufficiently inconsequential, but you're right to check.
>
> The current tracepoint TRACE_POSTGRESQL_LWLOCK_RELEASE really means
> "releaseD". It's appropriate to emit this as soon as the lock could be
> acquired by anything else. By deferring it until we'd processed the
> waitlist and woken other backends the window during which the lock was
> reported as "held" was longer than it truly was, and it was easy to see
> one backend acquire the lock while another still appeared to hold it.

From the archeology department: The TRACE_POSTGRESQL_LWLOCK_RELEASE
probe was in the right place until PG 9.4, but was then moved by
ab5194e6f617a9a9e7aadb3dd1cee948a42d0755, which was a major rewrite, so
it seems the move might have been accidental. The documentation
specifically states that the probe is triggered before waiters are woken
up, which it specifically does not do at the moment. So this looks like
a straight bug fix to me.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-03-19 20:06:57 Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
Previous Message Tom Lane 2021-03-19 19:46:08 Re: [PATCH] ProcessInterrupts_hook