On Fri, Jul 8, 2022 at 1:40 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Joe Conway <m...@joeconway.com> writes: > > It isn't clear to me if having a hook in the timeout handler is a > > nonstarter -- perhaps a comment with suitable warning for prospective > > extension authors is enough? Anyone else want to weigh in on this issue > > specifically? > > It doesn't seem like a great place for a hook, because the list of stuff > you could safely do there would be mighty short, possibly the empty set. > Write to shared memory? Not too safe. Write to a file? Even less. > Write to local memory? Pointless, because we're about to _exit(1). > Pretty much anything I can think of that you'd want to do is something > we've already decided the core code can't safely do, and putting it > in a hook won't make it safer.
I agree with this. But, all of the areas that v2-0003 touched for connectivity failures, they typically are emitting ereport(FATAL,/ereport(COMMERROR, (in ProcessStartupPacket) and we have emit_log_hook already being exposed and the implementers can, literally, do anything the hook. Looking at v2-0003 patch and emit_log_hook, how about we filter out for those connectivity errors either based on error codes and if they aren't unique, perhaps passing special flags to ereport API indicating that it's a connectivity error and in the emit_log_hook we can look for those connectivity error codes or flags to collect the stats about the failure connections (with MyProcPort being present in emit_log_hook)? This way, we don't need a new hook. Thoughts? Regards, Bharath Rupireddy.
