Date: Thu, 26 Sep 2019 11:56:21 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Mike Palmiotto <mike.palmiotto@crunchydata.com>
Cc: Yuli Khodorkovskiy <yuli.khodorkovskiy@crunchydata.com>,
	Tom Lane <tgl@sss.pgh.pa.us>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Auxiliary Processes and MyAuxProc
Message-ID: <20190926145621.GA22843@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAMN686G+DAJJFt1WN=uwrN4F5TpwqKjuJa_61TArqHR=L=4PJw@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On 2019-Sep-26, Mike Palmiotto wrote:

> On Thu, Sep 26, 2019 at 9:49 AM Alvaro Herrera <alvherre@2ndquadrant.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