Re: [PATCH] Log crashed backend's query (activity string)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Marti Raudsepp <marti(at)juffo(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Log crashed backend's query (activity string)
Date: 2011-09-06 21:03:30
Message-ID: CA+Tgmoa_Z6NGF68pv9S_0=1b7DR0T4dtoRwiXvF8R=F-5Y4USg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 6, 2011 at 4:52 PM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:
> This patch adds the backend's current running query to the "backend
> crash" message.
>
> The crashing query is often a good starting point in debugging the
> cause, and much more easily accessible than core dumps.
>
> Example output:
> LOG:  server process (PID 31451) was terminated by signal 9: Killed
> DETAIL:  Running query: DO LANGUAGE plpythonu 'import os;os.kill(os.getpid(),9)'
>
> The message "Running query" might not be entirely true, as it might be
> e.g. a vacuum activity string too. But it sounds better than "Activity
> string" or anything else I could come up with.
>
> Also refactored pgstat_get_backend_current_activity() such that it
> always returns consistent results. (Previously it returned a pointer to
> shared memory that could theoretically change and was vulnerable to
> races) The function can also deal with shared memory corruption (if
> isCrashed is true), so that corruption doesn't cause a postmaster crash
> or hang.

I haven't looked at the patch, but boy would this save me a lot of
support headaches if we can make it work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-09-06 21:16:58 Re: timezone GUC
Previous Message Robert Haas 2011-09-06 20:58:48 Re: [v9.1] sepgsql - userspace access vector cache