Re: Auxiliary Processes and MyAuxProc

From: Mike Palmiotto <mike(dot)palmiotto(at)crunchydata(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(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 22:03:24
Message-ID: CAMN686GvAswvOYMTYA1SpRvFkDk=7RmBrRwb16Es133O6Az0fA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 26, 2019 at 10:56 AM Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
>
> 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.

Thanks for the feedback! I've rebased and tested on my F30 box with
and without EXEC_BACKEND. Just working on splitting out the patches
now and will post the new patchset as soon as that's done (hopefully
sometime tomorrow).

--
Mike Palmiotto
https://crunchydata.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-09-26 22:25:25 Instability of partition_prune regression test results
Previous Message Tomas Vondra 2019-09-26 21:46:06 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions