On Fri, Jan 8, 2021 at 3:43 PM Drouvot, Bertrand <bdrou...@amazon.com> wrote: > > > On 1/8/21 7:24 AM, Fujii Masao wrote: > > CAUTION: This email originated from outside of the organization. Do > > not click links or open attachments unless you can confirm the sender > > and know the content is safe. > > > > > > > > On 2021/01/08 14:02, Drouvot, Bertrand wrote: > >> Hi, > >> > >> On 1/7/21 4:51 PM, Fujii Masao wrote: > >>> Thanks for the review! I pushed the latest patch. > >>> > >> Thanks all of you for your precious help on this patch! > >> > >> The original idea behind this thread has been split into 3 pieces. > >> > >> Pieces 1 (9d0bd95fa90a7243047a74e29f265296a9fc556d) and 2 > >> (0650ff23038bc3eb8d8fd851744db837d921e285) have now been committed, > >> the last one is to add more information regarding the canceled > >> statements (if any), like: > >> > >> * What was the blocker(s) doing? > > > > This "canceled statement" is just one that's canceled by recovery > > conflict? > > If so, the blocker is always the startup process? Sorry maybe I fail to > > understand this idea well.. > > > > > By blocker, I meant the one being canceled (I had in mind the startup > process being the blocked one, not the blocker one).
Thanks! Understood. > Sorry if i have not > been clear enough. > > As an example, it could provide things like: > > 2020-06-15 06:48:54.778 UTC [7037] LOG: about to interrupt pid: 7037, > backend_type: client backend, state: active, wait_event_type: Timeout, > wait_event: PgSleep, query_start: 2020-06-15 06:48:13.008427+00 Sorry I'm not sure yet how this information is actually useful. What is the actual use case of this information? Maybe this topic should be discussed in new thread. Regards, -- Fujii Masao
