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