Reporting query on crash even if completed

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Reporting query on crash even if completed
Date: 2017-09-18 08:52:44
Message-ID: 20170918085244.uonqzmdhpbpoo6gn@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)hagander(dot)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 field containing just
query text.

The query text will now mean "current query" when a query is running
and "last query" in other states. Accordingly,the field 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 - along with 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitriy Sarafannikov 2017-09-18 08:59:56 Re: Improving DISTINCT with LooseScan node
Previous Message Dmitry Dolgov 2017-09-18 08:31:54 Re: [PATCH] Generic type subscripting