Re: Problem with dumping bloom extension - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Problem with dumping bloom extension
Date
Msg-id 20160608015839.GA803316@tornado.leadboat.com
Whole thread Raw
In response to Re: Problem with dumping bloom extension  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Problem with dumping bloom extension  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Tue, Jun 07, 2016 at 03:23:46PM -0400, Robert Haas wrote:
> On Tue, Jun 7, 2016 at 2:40 PM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
> > On 6/7/16 11:16 AM, Stephen Frost wrote:
> >>
> >> Moved to CLOSE_WAIT.
> >
> > Could you add an explanation on the wiki page about what this section means?
> 
> Noah created that section.  My interpretation is that it's supposed to
> be for things we think are fixed, but maybe there's a chance they
> aren't - like a performance problem that we've patched but not
> received confirmation from the original reporter that the patch fixes
> it for them.  I'm inclined to think that most issues should just
> become "resolved" right away.

Yep, pretty much that.  CLOSE_WAIT is for performance defects, race
conditions, and other defects where a successful fix is difficult to verify
beyond reasonable doubt.  Other things can move directly to "resolved".  I
don't mind if practice diverges from that intent, and I don't really process
the two sections differently.



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Parallel pg_dump's error reporting doesn't work worth squat
Next
From: Michael Paquier
Date:
Subject: Re: [BUGS] BUG #14155: bloom index error with unlogged table