From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Mike Palmiotto <mike(dot)palmiotto(at)crunchydata(dot)com> |
Cc: | Yuli Khodorkovskiy <yuli(dot)khodorkovskiy(at)crunchydata(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Auxiliary Processes and MyAuxProc |
Date: | 2019-09-26 14:56:21 |
Message-ID: | 20190926145621.GA22843@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-Sep-26, Mike Palmiotto wrote:
> On Thu, Sep 26, 2019 at 9:49 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> >
> > 0002 seems way too large (and it doesn't currently apply). Is there
> > something we can do to make it more manageable?
>
> Initially we were thinking of submitting one patch for the
> centralization work and then separate patches per backend type. We
> opted not to go that route, mainly because of the number of resulting
> patches (there were somewhere around 13 total, as I remember). If it
> makes sense, we can go ahead and split the patches up in that fashion
> after rebasing.
Well, I think it would be easier to manage as split patches, yeah.
I think it'd be infrastructure that needs to be carefully reviewed,
while the other ones are mostly boilerplate. If I were the committer
for it, I would push that initial patch first immediately followed by
conversion of some process that's heavily exercised in buildfarm, wait
until lack of trouble is evident, followed by a trickle of pushes to
adapt the other processes.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2019-09-26 15:09:45 | Re: Add comments for a postgres program in bootstrap mode |
Previous Message | Alvaro Herrera | 2019-09-26 14:51:54 | Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown) |