Re: pg_background (and more parallelism infrastructure patches)

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_background (and more parallelism infrastructure patches)
Date: 2014-09-09 10:00:23
Message-ID: CAA4eK1JFk7E3MWkmOTVFoFoDZQX46PRcQryc0jcA_-sBz2kgNg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 9, 2014 at 2:32 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Sep 8, 2014 at 2:05 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> >> Another point about error handling is that to execute the sql in
> >> function pg_background_worker_main(), it starts the transaction
> >> which I think doesn't get aborted if error occurs
> >
> > For this I was just referring error handling code of
> > StartBackgroundWorker(), however during shutdown of process, it
> > will call AbortOutOfAnyTransaction() which will take care of aborting
> > transaction.
>
> Yeah.
>
> >> and similarly handling
> >> for timeout seems to be missing in error path.
> >
> > As we are anyway going to exit on error, so not sure, if this will be
> > required, however having it for clean exit seems to be better.
>
> Can you be more specific?

I was thinking to handle errors similar to what PostgreMain does,
however if it is going to exit then it might no be worth.

> I'm generally of the view that there's little point in spending time
> cleaning things up that will go away anyway when the process exits.

Yeah, in that case it might not make much sense. The argument here
could be why it has to exit, why can't it wait till the launcher asks it
to exit. You have mentioned in previous mail that you want to stick to
the approach taken by patch, however it is not clear why you think that
is better. If I try to think about how the worker backend should behave
incase the master backend assigns some task to worker, then I think it
would be sensible for worker to not exit after completing it's task (either
it has finished the execution of work assigned or otherwise) as master
backend can assign further tasks to the same worker. Another advantage
would be that setup and tear down cost of worker will be saved. Now If
we just think w.r.t pg_background it might not be so important to let
worker wait till launcher asks to quit, however as you have mentioned
in your mail upthread that you are expecting this kind of set-up for actual
parallelism, so it might not be completely insensible to expect worker
to wait till it has been asked to quit.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2014-09-09 10:24:47 Re: Scaling shared buffer eviction
Previous Message Heikki Linnakangas 2014-09-09 09:57:53 Re: LIMIT for UPDATE and DELETE