Re: [PATCH] Identify LWLocks in tracepoints

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: [PATCH] Identify LWLocks in tracepoints
Дата
Msg-id 15f8bca7-1387-cc7a-e20b-8fc0b00f3669@enterprisedb.com
обсуждение исходный текст
Ответ на Re: [PATCH] Identify LWLocks in tracepoints  (Craig Ringer <craig.ringer@enterprisedb.com>)
Ответы Re: [PATCH] Identify LWLocks in tracepoints  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список 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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] ProcessInterrupts_hook
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch