On 12/27/16 11:17 AM, Greg Stark wrote:
>
>
> On Dec 24, 2016 5:44 PM, "Tom Lane" <tgl@sss.pgh.pa.us
> <mailto:tgl@sss.pgh.pa.us>> wrote:
>
> I think we'd need at least an order of
> magnitude cheaper to consider putting timing calls into spinlock or
> lwlock
> paths, and that's just not available at all, let alone portably.
>
>
> For spinlocks we could conceivably just bite the bullet and use a raw
> rdtsc or the equivalent for other platforms. It might be pretty easy to
> distinguish sane numbers from numbers that result after a process
> reschedule and we could just discard data when that happens (or count
> occurrences).
>
> That may possibly work for spinlocks but it won't work for anything
> heavier where process reschedules are routine.
Anything heavier and a ~50ns gettimeofday() call is probably not that
bad anymore...
I also wonder if setting an alarm is cheap enough to happen during a
spinlock? Set a fairly short alarm on entry, clear it on exit. If the
alarm fires, do the gettimeofday(). Add the alarm time back in and
you're going to be close enough to when the wait started for any
practical use of pg_stat_activity (perhaps this is what Stephen is
suggesting about deadlock timeout...)
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)