[HACKERS] Reporting query on crash even if completed - Mailing list pgsql-hackers

From Andres Freund
Subject [HACKERS] Reporting query on crash even if completed
Date
Msg-id 20170918085244.uonqzmdhpbpoo6gn@alap3.anarazel.de
Whole thread Raw
Responses Re: [HACKERS] Reporting query on crash even if completed
List pgsql-hackers
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
pgstat_get_crashed_backend_activity() can find a query string.

That used to be only when there's an active query, but since
commit 4f42b546fd87a80be30c53a0f2c897acb826ad52
Author: Magnus Hagander <magnus@hagander.net>
Date:   2012-01-19 14:19:20 +0100
   Separate state from query string in pg_stat_activity
   This separates the state (running/idle/idleintransaction etc) into   it's own field ("state"), and leaves the query
fieldcontaining just   query text.
 
   The query text will now mean "current query" when a query is running   and "last query" in other states.
Accordingly,thefield has been   renamed from current_query to query.
 
   Since backwards compatibility was broken anyway to make that, the procpid   field has also been renamed to pid -
alongwith the same field in   pg_stat_replication for consistency.
 
   Scott Mead and Magnus Hagander, review work from Greg Smith

that's not the case anymore. I can't recall anybody complaining, but to
me it seems fairly confusing to report that some query was running when
it's actually not.

Magnus, was that intentional?  Others, does anybody think we want it
this way?


Both manually signalling and the OOM killer probably are the biggest
source for backends being killed even when there's no queries currently
running.

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: [HACKERS] [PATCH] Generic type subscripting
Next
From: Dmitriy Sarafannikov
Date:
Subject: Re: [HACKERS] Improving DISTINCT with LooseScan node