On Sun, Dec 18, 2016 at 10:33 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Sat, Dec 17, 2016 at 5:41 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Dec 14, 2016 at 3:25 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> Thoughts?
>>
>> Hearing no objections, I've gone ahead and committed this. If that
>> makes somebody really unhappy I can revert it, but I am betting that
>> the real story is that nobody cares about preserving T_ID().
>
> I suppose LWLock could include a uint16 member 'id' without making
> LWLock any larger, since it would replace the padding between
> 'tranche' and 'state'. But I think a better solution, if anyone
> really wants these T_ID numbers from a dtrace script, would be to add
> lock address to the existing lwlock probes, and then figure out a way
> to add some new probes to report the base and stride in the right
> places so you can do the book keeping in dtrace variables.
Interesting idea. My bet is that nobody cares about dtrace very much.
probes.d was first added in 2006, and continued to gradually get new
probes (all from submissions by Robert Lor) until 2009. Since then,
nothing has happened except for perfunctory maintenance by various
committers trying to solve other problems who had to maintain the work
that had already been done whether they cared about it or not. (I
notice that the probes lwlock-acquire-or-wait and
lwlock-acquire-or-wait-fail have never been documented.) I would be
tempted to rip the whole thing out as an attractive nuisance, except
that I bet somebody would complain about that...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company