Re: background sessions

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Borodin <amborodin(at)acm(dot)org>, amul sul <sulamul(at)gmail(dot)com>
Subject: Re: background sessions
Date: 2017-03-14 07:31:15
Message-ID: CAFj8pRDPSYXYydgD+eHO-uVH=Tb0Qs-DSE_JB+HC=zyKf1=jPg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2017-03-13 21:22 GMT+01:00 Robert Haas <robertmhaas(at)gmail(dot)com>:

> On Sat, Mar 11, 2017 at 10:11 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > 2017-03-09 14:52 GMT+01:00 Peter Eisentraut
> > <peter(dot)eisentraut(at)2ndquadrant(dot)com>:
> >>
> >> On 3/8/17 14:22, Pavel Stehule wrote:
> >> > 1. will be background session process closed automatically when parent
> >> > process is closed?
> >>
> >> If the communications queue goes away the process will eventually die.
> >> This is similar to how a backend process will eventually die if the
> >> client goes away. Some more testing would be good here.
> >
> >
> > what means "eventually die"?
> >
> > I called pg_sleep() in called subprocess.
> >
> > Cancel, terminating parent process has not any effect. It is maybe
> > artificial test.
> >
> > Little bit more realistic - waiting on table lock in background worker
> was
> > successful - and when parent was cancelled, then worker process was
> > destroyed too.
> >
> > But when parent was terminated, then background worker process continued.
> >
> > What is worse - the background worker had 100% CPU and I had to restart
> > notebook.
> >
> > CREATE OR REPLACE FUNCTION public.foo()
> > RETURNS void
> > LANGUAGE plpythonu
> > AS $function$
> > with plpy.BackgroundSession() as a:
> > a.execute('update foo2 set a = 30')
> > a.execute('insert into foo2 values(10)')
> > $function$
> > postgres=#
> >
> >
> > I blocked foo2 in another session.
>
> I'm not sure what's going on with this patch set, but in general a
> background process can't just go away when the foreground process goes
> away. We could arrange to kill it, a la pg_terminate_backend(), or we
> can let it keep running, and either of those things might be what
> somebody wants, depending on the situation. But it can't just vanish
> into thin air.
>

I understand, so there are not one solution only - and process maintenance
is hard.

Very often strategy can be recheck of parent process in some waiting
cycles. It should not to impact performance.

I afraid so some waiting times in bg process can be high probable with this
patch - and then is probable so somebody use pg_terminate_backend. This
situation should not to finish by server restart.

Regards

Pavel

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message tushar 2017-03-14 07:31:47 Re: increasing the default WAL segment size
Previous Message Michael Paquier 2017-03-14 07:03:05 Re: allow referring to functions without arguments when unique