Re: pg9.6 segfault using simple query (related to use fk for join estimates)

From: Noah Misch <noah(at)leadboat(dot)com>
To: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Stefan Huehner <stefan(at)huehner(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: pg9.6 segfault using simple query (related to use fk for join estimates)
Date: 2016-06-04 21:40:37
Message-ID: 20160604214037.GA704595@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 03, 2016 at 10:32:24AM -0400, Noah Misch wrote:
> On Wed, Jun 01, 2016 at 09:29:54PM -0400, Noah Misch wrote:
> > On Sun, May 29, 2016 at 01:36:01AM -0400, Noah Misch wrote:
> > > On Fri, May 06, 2016 at 03:06:01PM -0400, Robert Haas wrote:
> > > > On Thu, May 5, 2016 at 10:48 AM, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> > > > > Ok, so I spoke to Tomas about this briefly, and he's asked me to send
> > > > > in this patch. He didn't get time to look over it due to some other
> > > > > commitments he has today.
> > > > >
> > > > > I do personally feel that if the attached is not good enough, or not
> > > > > very close to good enough then probably the best course of action is
> > > > > to revert the whole thing.
> > > >
> > > > Tom, what do you think about this patch? Is it good enough, or should
> > > > we revert the whole thing?
> > >
> > > [This is a generic notification.]
> > >
> > > The above-described topic is currently a PostgreSQL 9.6 open item. Simon,
> > > since you committed the patch believed to have created it, you own this open
> > > item. If some other commit is more relevant or if this does not belong as a
> > > 9.6 open item, please let us know. Otherwise, please observe the policy on
> > > open item ownership[1] and send a status update within 72 hours of this
> > > message. Include a date for your subsequent status update. Testers may
> > > discover new open items at any time, and I want to plan to get them all fixed
> > > well in advance of shipping 9.6rc1. Consequently, I will appreciate your
> > > efforts toward speedy resolution. Thanks.
> >
> > This PostgreSQL 9.6 open item is past due for your status update. Kindly send
> > a status update within 24 hours, and include a date for your subsequent status
> > update. Refer to the policy on open item ownership:
> > http://www.postgresql.org/message-id/20160527025039.GA447393@tornado.leadboat.com
>
> IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 9.6 open item is long past due
> for your status update. Please reacquaint yourself with the policy on open
> item ownership[1] and then reply immediately. If I do not hear from you by
> 2016-06-04 15:00 UTC, I will transfer this item to release management team
> ownership without further notice.
>
> [1] http://www.postgresql.org/message-id/20160527025039.GA447393@tornado.leadboat.com

This PostgreSQL 9.6 open item now needs a permanent owner. I want PostgreSQL
to have this planner functionality, but I cannot both give it the attention it
needs and meet commitments predating this open item. Would any other
committer like to take ownership? If this role interests you, please read
this thread and the policy linked above, then send an initial status update
bearing a date for your subsequent status update. If the item does not have a
permanent owner by 2016-06-07 22:00 UTC, I will resolve the item by reverting
commits 68d704e and 137805f.

Thanks,
nm

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2016-06-04 21:54:16 Re: COMMENT ON, psql and access methods
Previous Message Kevin Grittner 2016-06-04 20:21:49 Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <