Re: bg worker: patch 1 of 6 - permanent process
От | Markus Wanner |
---|---|
Тема | Re: bg worker: patch 1 of 6 - permanent process |
Дата | |
Msg-id | 4C763CC4.6040201@bluegap.ch обсуждение исходный текст |
Ответ на | Re: bg worker: patch 1 of 6 - permanent process (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: bg worker: patch 1 of 6 - permanent process
|
Список | pgsql-hackers |
Hi, thanks for your feedback on this, it sort of got lost below the discussion about the dynamic shared memory stuff, IMO. On 08/26/2010 04:39 AM, Robert Haas wrote: > It's not clear to me whether it's better to have a single coordinator > process that handles both autovacuum and other things, or whether it's > better to have two separate processes. It has been proposed by Alvaro and/or Tom (IIRC) to reduce code duplication. Compared to the former approach, it certainly seems cleaner that way and it has helped reduce duplicate code a lot. I'm envisioning such a coordinator process to handle coordination of other background processes as well, for example for distributed and/or parallel querying. Having just only one process reduces the amount of interaction required between coordinators (i.e. autovacuum shouldn't ever start on databases for which replication didn't start, yet, as the autovacuum worker would be unable to connect to the database at that stage). It also reduces the amount of extra processes required, and thus I think also general complexity. What'd be the benefits of having separate coordinator processes? They'd be doing pretty much the same: coordinate background processes. (And yes, I clearly consider autovacuum to be just one kind of background process). > I agree with this criticism, but the other thing that strikes me as a > nonstarter is having the postmaster participate in the imessages > framework. This is simply not the case (anymore). (And one of the reasons a separate coordinator process is required, instead of letting the postmaster do this kind of coordination). > Our general rule is that the postmaster must avoid > touching shared memory; else a backend that scribbles on shared memory > might take out the postmaster, leading to a failure of the > crash-and-restart logic. That rule is well understood and followed by the bg worker infrastructure patches. If you find code for which that isn't true, please point at it. The crash-and-restart logic should work just as it did with the autovacuum launcher. Regards Markus
В списке pgsql-hackers по дате отправления: