Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

On Wed, Mar 2, 2016 at 5:41 AM, Magnus Hagander wrote: > Ok, I've pushed a code that does that. Thank you. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

On Wed, Mar 2, 2016 at 7:34 AM, Michael Paquier wrote: > On Wed, Mar 2, 2016 at 9:19 PM, Magnus Hagander > wrote: > > Needs Review -> Needs Review > > Waiting on Author -> Refuse moving > > Ready for committer -> Ready for Committer > > Committed

Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

On Wed, Mar 2, 2016 at 9:19 PM, Magnus Hagander wrote: > Needs Review -> Needs Review > Waiting on Author -> Refuse moving > Ready for committer -> Ready for Committer > Committed -> refuse moving > Moved to next cf -> refuse moving (if it's already set like this, it would >

Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

On Tue, Mar 1, 2016 at 10:27 AM, Tom Lane wrote: > Alvaro Herrera writes: > > Magnus Hagander wrote: > >> That said, we can certainly reconsider that. Would we always copy the > value > >> over? Even if it was, say, rejected? (so it would be copied

Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

On Tue, Mar 1, 2016 at 7:27 AM, Tom Lane wrote: > +1 for not moving such patches to the new CF until the author does > something --- at which point they'd change to "Needs Review" state. > But we should not change them into that state without author input. > And I don't see

Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

Alvaro Herrera writes: > Magnus Hagander wrote: >> That said, we can certainly reconsider that. Would we always copy the value >> over? Even if it was, say, rejected? (so it would be copied to the new CF >> but still marked rejected) Or is there a subset of behaviors

Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

Magnus Hagander wrote: > On Tue, Feb 16, 2016 at 11:12 PM, Pavel Stehule > wrote: > > This behave is pretty unpleasant and frustrating. > > Well, it's in no way a bug, because it's the behavior we agreed upon at the > time :) I guess the "move to next CF" operation is

Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

On Tue, Feb 16, 2016 at 11:12 PM, Pavel Stehule wrote: > > > 2016-02-17 3:19 GMT+01:00 Jim Nasby : > >> 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

Re: Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

2016-02-17 3:19 GMT+01:00 Jim Nasby : > 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

Commitfest Bug (was: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)

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