Best way to start PG (Process Groups)

What is the best way of starting pg ?

  • Manually calling pg:start_link() ?
  • Inside the top supervisor?
  • Through kernel config by setting {start_pg, true} ?

Problem by using {start_pg, true} :

{shell, [
    {apps, [my_app]},
    {config, "./config/my.config"}
]}.

Inside my.config i have:
{kernel, [{start_pg, true}]},
I noticed that if I start pg with kernel config, rebar3 shell does not have pg running.
Although i can clearly match true = application:get_env(kernel, start_pg).
If i release with the same config i have pg running, so the option works.

Is rebar3 already starting kernel before evaluating the config ?
If so, why does it handle stuff like logger configurations and not other settings as start_pg?
Ultimately, how can i have pg running both in shell and in release in the most clean way?

2 Likes

I decided that I didn’t want a “globally” shared scope for my process groups (I use them mainly for pub/sub right now), so I just start them in my own supervisor as

#{
    id => my_pg,
    start => {pg, start_link, [my_pg_scope]}
}
4 Likes

I ended up with this solution since it seams to be the best option. Thank you!

1 Like

Yes. You can run ERL_FLAGS="-kernel start_pg true" rebar3 shell if you want the default scope supervised by the kernel.

My recommendation would be to have a scope supervised by your own application supervisor (this answer is already marked). That’s how pg was designed to work anyway. The default scope was mainly done for a simplified migration from pg2.

3 Likes