Re: pg_background (and more parallelism infrastructure patches)

On Wed, Oct 22, 2014 at 7:12 PM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>> I don't think pg_background is merely a test program: I think it's a
>> quite useful piece of functionality. It can be used for running
>> VACUUM from a procedure, which is something people have asked for more
>> than once, or for simulating an autonomous transaction. Granted,
>> it'll be a lot slower than a real autonomous transaction, but it's
>> still better than doing it via dblink, because you don't have to futz
>> with authentication.
>
> I think this is a very useful program but I wonder if it makes more sense to
> push it out to pgxn? Why do we need an ever growing contrib? Further, if it
> is good enough to go into contrib, why isn't it just in core?

Sure, there's always this debate. Certainly, there's no reason it has
to be in contrib rather than core or PGXN. From my point of view,
putting it on PGXN would be a less-than-awesome development because
then the infrastructure that the patch introduces (patches 1-5 of the
series) would have no users in core or contrib, which means that (A)
if anyone is thinking of modifying that code in the future, they'll
have more difficulty knowing whether their changes break anything and
(B) if someone breaks something unwittingly, the buildfarm will not
tell us.

Now, admittedly, I expect that eventually all of this stuff will be
used in core - for parallelism. But in the meantime I think having at
least one example in the PostgreSQL source tree of how each piece of
extensibility infrastructure that we have can be used is handy and
useful and generally something that we ought to encourage. And this
one has the advantage - unlike some stuff in contrib - of actually
being somewhat useful for real work, which a decent amount of the
stuff in contrib isn't.

What about moving it the opposite direction, from contrib all the way
into core? The main advantage of that in my book is that it might
make it easier to reduce the code duplication between pg_background
and exec_simple_query; the main disadvantage is that it reduces the
super-user's control, because now the functionality is always
available instead of being something that the super-user can choose to
install, or not.

But these are all judgement calls, of course.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company