Re: [HACKERS] Reporting query on crash even if completed

2017-09-18 Thread Magnus Hagander
On Mon, Sep 18, 2017 at 6:12 PM, Robert Haas wrote: > On Mon, Sep 18, 2017 at 9:47 AM, Tom Lane wrote: > > Now, for pg_stat_activity part of the argument why this wouldn't be > > confusing was that you could also see the "state" field. Maybe we > >

Re: [HACKERS] Reporting query on crash even if completed

2017-09-18 Thread Tom Lane
Robert Haas writes: > On Mon, Sep 18, 2017 at 9:47 AM, Tom Lane wrote: >> Now, for pg_stat_activity part of the argument why this wouldn't be >> confusing was that you could also see the "state" field. Maybe we >> should try to shoehorn equivalent info

Re: [HACKERS] Reporting query on crash even if completed

2017-09-18 Thread Robert Haas
On Mon, Sep 18, 2017 at 9:47 AM, Tom Lane wrote: > Now, for pg_stat_activity part of the argument why this wouldn't be > confusing was that you could also see the "state" field. Maybe we > should try to shoehorn equivalent info into the crash log entry? Yeah, I think so.

Re: [HACKERS] Reporting query on crash even if completed

2017-09-18 Thread Tom Lane
Andres Freund writes: > When a backend dies, in a manner triggering a crash restart, we > currently log something like: > DETAIL: Failed process was running: %s > > That used to be only when there's an active query, but since > commit 4f42b546fd87a80be30c53a0f2c897acb826ad52

[HACKERS] Reporting query on crash even if completed

2017-09-18 Thread Andres Freund
Hi, When a backend dies, in a manner triggering a crash restart, we currently log something like: LOG: %s (PID %d) was terminated by signal %d LOG: %s (PID %d) exited with exit code %d DETAIL: Failed process was running: %s Notably we log the query from the backend whenever