From: Justin Pryzby <pryzby@telsasoft.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: pgsql-hackers@postgresql.org
Subject: Re: SIGSEGV in BRIN autosummarize
Date: Wed, 18 Oct 2017 11:48:55 -0500
Message-ID: <20171018164855.GC17895@telsasoft.com> (raw)
In-Reply-To: <20171017140740.GD13880@telsasoft.com>
References: <20171014224220.GB22678@telsasoft.com>
<20171017105916.3rvmznxnuphn3uph@alvherre.pgsql>
<20171017122922.GC13880@telsasoft.com>
<5648.1508247264@sss.pgh.pa.us>
<20171017140740.GD13880@telsasoft.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On Tue, Oct 17, 2017 at 09:07:40AM -0500, Justin Pryzby wrote:
> On Tue, Oct 17, 2017 at 09:34:24AM -0400, Tom Lane wrote:
> > Justin Pryzby <pryzby@telsasoft.com> writes:
> > > On Tue, Oct 17, 2017 at 12:59:16PM +0200, Alvaro Herrera wrote:
> > >> Anyway, can give this patch a try?
> >
> > The trick in this sort of situation is to make sure you build binaries
> > that match your existing install in every way except having the added
> > patch, and maybe getting installed into a different directory.
>
> I'm familiar with that process; but, these are PG10 binaries from PGDG for
> centos6 x64. I had to add symlinks for postgis library, but otherwise seems to
> be working fine (although I didn't preserve as many configure options as your
> message would suggest I should have).
On Tue, Oct 17, 2017 at 12:49:55PM -0400, Tom Lane wrote:
> So what I'm thinking is that you need an error during perform_work_item,
> and/or more than one work_item picked up in the calling loop, to make this
> bug manifest. You would need to enter perform_work_item in a
..in our case probably due to interruption by LOCK TABLE, yes?
On Tue, Oct 17, 2017 at 12:49:55PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > And I think that's because we're not
> > checking that the namespace OID is a valid value before calling
> > get_namespace_name on it.
>
> The part of your patch that adds a check on avw_database is clearly
> correct and necessary. I'm thinking the change you propose in
> perform_work_item is just overcomplicating code that's okay as it
> stands. We don't need to optimize for the schema-went-away case.
No crashes in ~28hr. It occurs to me that it's a weaker test due to not
preserving most compilation options. If I understand, our crash isn't
explained by the avw_database test anyway (?)
Should I make clean and recompile with all non-prefix options and a minimal
patch (avw_database==MyDatabaseId || continue) ?
Or recompile with existing options but no patch to first verify crash occurs
with locally compiled binary?
Justin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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-hackers@postgresql.org
Cc: pryzby@telsasoft.com, tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org
Subject: Re: SIGSEGV in BRIN autosummarize
In-Reply-To: <20171018164855.GC17895@telsasoft.com>
* 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