Re: pg_background (and more parallelism infrastructure patches) - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: pg_background (and more parallelism infrastructure patches)
Date
Msg-id 20141110183757.GO28859@tamriel.snowman.net
Whole thread Raw
In response to Re: pg_background (and more parallelism infrastructure patches)  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: pg_background (and more parallelism infrastructure patches)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
* Andres Freund (andres@2ndquadrant.com) wrote:
> > 1. Any other opinions for or against pg_background as a concept?  I
> > thought the ability to kick of vacuums (or other stuff with
> > PreventTransactionChain) asynchronously was pretty cool, as we as the
> > ability to use it as an authentication-free loopback dblink.  But
> > opinions obviously vary.
>
> I think it's a cool concept, but I'm not sure if it's worth the work to
> make it fully usable. Or rather, I think it's worthy enough, but I
> personally would priorize other stuff.

I've not read through the whole thread/discussionm but I'd put myself in
more-or-less the same boat at this point.  I've got a number of other
things on my plate already that need to get done (more RLS cleanup /
consistency, back-patching the ereport() column-privs issue, reviewing
pgAudit, the less-than-superuser privileges work, actually helping out
with the in-progress commitfest..) and so I really doubt I'd be able to
seriously help with pg_background- at least for 9.5, which is coming up
awful fast at this point, if we're going to stick with the 'normal'
schedule and freeze in the spring.

That said, I love the concept and had really been hoping to see it in
9.5, and maybe some at or cron-like ability happening later (yes, I
absolutely feel we need this, though I know others have different
opinions..).

> > 2. Is anyone sufficiently interested in pg_background as a concept
> > that they'd be willing to take over the patch and work on the TODO
> > list mentioned above?
>
> I personally won't. If we can come up with a sketch of how to deal with
> the data transport encoding issue above, I'd be willing to to work on
> that specific part. But not pg_background in itself.

If other things get done or additional resources show up, I'd be
interested in helping, but I don't see either happening in time for 9.5.
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Proposal: Log inability to lock pages during vacuum
Next
From: Alvaro Herrera
Date:
Subject: Re: pg_background (and more parallelism infrastructure patches)