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