From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: mailtch@163.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17481: sometime pg_stat_statements coredump
Date: Tue, 17 May 2022 08:52:57 +0900
Message-ID: <YoLj2fcRQ5KZXAj0@paquier.xyz> (raw)
In-Reply-To: <1371138.1652714481@sss.pgh.pa.us>
References: <17481-953591f62b3f8a58@postgresql.org>
<1371138.1652714481@sss.pgh.pa.us>
On Mon, May 16, 2022 at 11:21:21AM -0400, Tom Lane wrote:
> Not much info here. Can you install the debug symbols for the postgres
> package you're using and repeat the backtrace? Another potentially useful
> bit of info would be the source text for the query that's causing the
> failure, which you could get with "p debug_query_string" in gdb.
CleanQuerytext() would crash on a NULL string AFAIK, but this really
smells like a case where a utility code path is freeing the pointer of
the query string that PGSS is attempting to look at. I have seen this
problem in the past, where this subtle issue could be created even if
the code was rather careful in the query string handling. Here, are
we dealing with a CALL that involves plpgsql? Or is that a different
language, like something out of core?
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: michael@paquier.xyz, tgl@sss.pgh.pa.us, mailtch@163.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17481: sometime pg_stat_statements coredump
In-Reply-To: <YoLj2fcRQ5KZXAj0@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox