Re: the s_lock_stuck on perform_spin_delay

From: Jim Nasby <jim(dot)nasby(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andy Fan <zhihuifan1213(at)163(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <tmunro(at)postgresql(dot)org>
Subject: Re: the s_lock_stuck on perform_spin_delay
Date: 2024-01-04 23:03:18
Message-ID: d6cf942d-f406-477a-8884-798e48091320@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 1/4/24 10:33 AM, Tom Lane wrote:<br>
</div>
<blockquote type="cite" cite="mid:498328(dot)1704386013(at)sss(dot)pgh(dot)pa(dot)us">
<pre><pre class="moz-quote-pre" wrap="">Robert Haas <a
class="moz-txt-link-rfc2396E" href="mailto:robertmhaas(at)gmail(dot)com"
moz-do-not-send="true">&lt;robertmhaas(at)gmail(dot)com&gt;</a> writes:
</pre><blockquote type="cite" style="color: #007cff;"><pre
class="moz-quote-pre" wrap="">On Thu, Jan 4, 2024 at 10:22 AM Tom Lane <a
class="moz-txt-link-rfc2396E" href="mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us"
moz-do-not-send="true">&lt;tgl(at)sss(dot)pgh(dot)pa(dot)us&gt;</a> wrote:
</pre><blockquote type="cite" style="color: #007cff;"><pre
class="moz-quote-pre" wrap="">We should be making an effort to ban coding patterns like
"return with spinlock still held", because they're just too prone
to errors similar to this one.
</pre></blockquote></blockquote><blockquote type="cite"
style="color: #007cff;"><pre class="moz-quote-pre" wrap="">I agree that we don't want to add overhead, and also about how
spinlocks should be used, but I dispute "easily detectable
statically." I mean, if you or I look at some code that uses a
spinlock, we'll know whether the pattern that you mention is being
followed or not, modulo differences of opinion in debatable cases. But
you and I cannot be there to look at all the code all the time. If we
had a static checking tool that was run as part of every build, or in
the buildfarm, or by cfbot, or somewhere else that raised the alarm if
this rule was violated, then we could claim to be effectively
enforcing this rule.
</pre></blockquote><pre class="moz-quote-pre" wrap="">I was indeed suggesting that maybe we could find a way to detect
such things automatically. While I've not been paying close
attention, I recall there's been some discussions of using LLVM/clang
infrastructure for customized static analysis, so maybe it'd be
possible without an undue amount of effort.</pre></pre>
</blockquote>
<p>FWIW, the lackey[1] tool in Valgrind is able to do some kinds of
instruction counting, so it might be possible to measure how many
instructions are actualyl being executed while holding a spinlock.
Might be easier than code analysis.</p>
<p>Another possibility might be using the CPUs timestamp counter.<br>
</p>
<p>1: <a class="moz-txt-link-freetext" href="https://valgrind.org/docs/manual/lk-manual.html">https://valgrind.org/docs/manual/lk-manual.html</a><br>
</p>
<pre class="moz-signature" cols="72">--
Jim Nasby, Data Architect, Austin TX</pre>
</body>
</html>

Attachment Content-Type Size
unknown_filename text/html 2.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2024-01-04 23:03:25 Re: Emit fewer vacuum records by reaping removable tuples during pruning
Previous Message Andres Freund 2024-01-04 22:54:03 Re: the s_lock_stuck on perform_spin_delay