Hi, On 2021-04-12 14:31:32 +0800, Craig Ringer wrote: > * There is no easy way to look up the tranche name by ID from outside the > backend
But it's near trivial to add that. > It's annoying that we have to pay the cost of computing the tranche name > though. It never used to matter, but now that T_NAME() expands to > GetLWTrancheName() calls as of 29c3e2dd5a6 it's going to cost a little more > on such a hot path. I might see if I can do a little comparison and see how > much. I could add TRACE_POSTGRESQL_<<tracepointname>>_ENABLED() guards since > we > do in fact build with SDT semaphore support. That adds a branch for each > tracepoint, but they're already marshalling arguments and making a function > call that does lots more than a single branch, so that seems pretty > sensible. I am against adding any overhead for this feature. I honestly think the probes we have right now in postgres do not provide a commensurate benefit. > (It'd be possible to instead generate probes for each GUC at compile-time > using the preprocessor and the DTRACE_ macros. But as noted above, that > doesn't currently work properly in the same compilation unit that a dtrace > script-generated probes.h is included in. I think it's probably nicer to > have specific probes for GUCs of high interest, then generic probes that > capture all GUCs anyway.) > > There are a TON of probes I want to add, and I have a tree full of them > waiting to submit progressively. Yes, ability to probe all GUCs is in > there. So is detail on walsender, reorder buffer, and snapshot builder > activity. Heavyweight lock SDTs. A probe that identifies the backend type > at startup. SDT probe events emitted for every wait-event. Probes in elog.c > to let probes observe error unwinding, capture error messages, > etc. [...] A probe that fires whenever debug_query_string > changes. Lots. But I can't submit them all at once, especially without > some supporting use cases and scripts that other people can use so > they can understand why these probes are useful. -1. This is not scalable. Adding static probes all over has both a runtime (L1I, branches, code optimization) and maintenance overhead. > (Those can also be used with systemtap guru mode scripts to do things > like turn a particular elog(DEBUG) into a PANIC at runtime for > diagnostic purposes). Yikes. Greetings, Andres Freund
