Hi, On 2020-11-18 18:41:27 -0300, Alvaro Herrera wrote: > The amount of stuff that this is doing with ProcArrayLock held > exclusively seems a bit excessive; it sounds like we could copy the > values we need first, release the lock, and *then* do all that memory > allocation and string printing -- it's a lock of code for such a > contended lock.
Yea, that's a good point. > Anytime a process sees itself as blocked by autovacuum > and wants to signal it, there's a ProcArrayLock hiccup (I didn't > actually measure it, but it's at least five function calls). I'm a bit doubtful it's that important - it's limited in frequency by deadlock_timeout. But worth improving anyway. > We could make this more concurrent by copying lock->tag to a local > variable, releasing the lock, then doing all the string formatting and > printing. See attached quickly.patch. Sounds like a plan. > Now, when this code was written (d7318d43d, 2012), this was a LOG > message; it was demoted to DEBUG1 later (d8f15c95bec, 2015). I think it > would be fair to ... remove the message? Or go back to Simon's original > formulation from commit acac68b2bca, which had this message as DEBUG2 > without any string formatting. I don't really have an opinion on this. Greetings, Andres Freund