Re: putting a bgworker to rest

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: putting a bgworker to rest
Date: 2013-04-24 17:01:16
Message-ID: CA+TgmoapsJTask11K_wx4vMF2yZyagKS8OOXdDcQhCKaKEEF2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 23, 2013 at 1:22 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> So a "done" worker would never be restarted, until postmaster sees a
>> crash or is itself restarted? I guess that'd be useful for workers
>> running during recovery, which terminate when recovery completes. Is
>> that your use case?
>
> Well, its not actual postgres recovery, but something similar in the
> context of logical replication.

It's probably too late to be twiddling this very much more, but
another thing I think would be useful is for backends to have the
ability to request that the postmaster start a worker of type xyz,
rather than having the server start it automatically at startup time.
That's what you'd need for parallel query, and there might be some
replication-related use cases for such things as well. The general
usage pattern would be:

- regular backend realizes that it needs help
- kicks postmaster to start a helper process
- helper process runs for a while, doing work
- helper process finishes work, maybe waits around for some period of
time to see if any new work arrives, and then exits
- eventually go back to step 1

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2013-04-24 17:16:07 Examples Re: Bug Fix: COLLATE with multiple ORDER BYs in aggregates
Previous Message Heikki Linnakangas 2013-04-24 16:34:32 Re: 9.3 Beta1 status report