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
>
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 |