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
> >
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
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.
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
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