Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates) - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)
Date
Msg-id CAFj8pRA7OTFdA7V+sayGg8Q4DFefn8ajn5mwm6Vaaj+keeU8Nw@mail.gmail.com
Whole thread Raw
In response to Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)
List pgsql-hackers


2016-02-17 3:19 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 2/16/16 12:38 AM, Michael Paquier wrote:
When a patch with status "Ready for committer" on CF N is moved to CF
(N+1), its status is automatically changed to "Needs Review". That's
something to be aware of when cleaning up the CF app entries.

I agree with Alvarro; this seems like a bug to me. If a patch is ready for committer in CF N, why would it suddenly not be ready in N+1?

+1,

This behave is pretty unpleasant and frustrating.

Regards

Pavel
 
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl
Next
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl