Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: ik(at)postgresql-consulting(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)
Date: 2014-10-02 12:23:09
Message-ID: 20141002122309.GK28859@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Craig Ringer (craig(at)2ndquadrant(dot)com) wrote:
> > The patch https://commitfest.postgresql.org/action/patch_view?id=885
> > (discussion starts here I hope -
> > http://www.postgresql.org/message-id/4FE8CA2C.3030809@uptime.jp)
> > demonstrates performance problems; LWLOCK_STAT, LOCK_DEBUG and
> > DTrace-like approach are slow, unsafe for production use and a bit
> > clumsy for using by DBA.
>
> It's not at all clear to me that a DTrace-like (or perf-based, rather)
> approach is unsafe, slow, or unsuitable for production use.

I've certainly had it take production systems down (perf, specifically),
so I'd definitely consider it "unsafe". I wouldn't say it's unusable,
but it's certainly not what we should have as the end-goal for PG.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-10-02 12:28:36 Re: Replication identifiers, take 3
Previous Message Marko Tiikkaja 2014-10-02 12:12:29 Re: pgcrypto: PGP signatures