Re: [HACKERS] Custom compression methods - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: [HACKERS] Custom compression methods
Date
Msg-id CAPpHfdtjDWBLNpaubsdByLqWJ0MfSLzGAHwXuP4SW0JRiPo3eQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Custom compression methods  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [HACKERS] Custom compression methods  (Ildus K <i.kurbangaliev@gmail.com>)
List pgsql-hackers
On Mon, Jul 1, 2019 at 5:51 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> On 2019-Jul-01, Alexander Korotkov wrote:
>
> > As I get we're currently need to make high-level decision of whether
> > we need this [1].  I was going to bring this topic up at last PGCon,
> > but I didn't manage to attend.  Does it worth bothering Ildus with
> > continuous rebasing assuming we don't have this high-level decision
> > yet?
>
> I agree that having to constantly rebase a patch that doesn't get acted
> upon is a bit pointless.  I see a bit of a process problem here: if the
> patch doesn't apply, it gets punted out of commitfest and reviewers
> don't look at it.  This means the discussion goes unseen and no
> decisions are made.  My immediate suggestion is to rebase even if other
> changes are needed.

OK, let's do this assuming Ildus didn't give up yet :)

> Longer-term I think it'd be useful to have patches
> marked as needing "high-level decisions" that may lag behind current
> master; maybe we have them provide a git commit-ID on top of which the
> patch applies cleanly.

+1,
Sounds like good approach for me.

> I recently found git-imerge which can make rebasing of large patch
> series easier, by letting you deal with smaller conflicts one step at a
> time rather than one giant conflict; it may prove useful.

Thank you for pointing, will try.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



pgsql-hackers by date:

Previous
From: Alexey Kondratov
Date:
Subject: Fix two issues after moving to unified logging system forcommand-line utils
Next
From: Konstantin Knizhnik
Date:
Subject: Re: [HACKERS] Cached plans and statement generalization