Re: [HACKERS] src/test/subscription/t/002_types.pl hanging onparticular environment
От | Craig Ringer |
---|---|
Тема | Re: [HACKERS] src/test/subscription/t/002_types.pl hanging onparticular environment |
Дата | |
Msg-id | CAMsr+YETUw_k8hoAPdqHnoBCeCoLO1YwM2HLQ-+_zu70_F=aLQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] src/test/subscription/t/002_types.pl hanging onparticular environment (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [HACKERS] src/test/subscription/t/002_types.pl hanging onparticular environment
|
Список | pgsql-hackers |
On 19 September 2017 at 20:33, Amit Kapila <amit.kapila16@gmail.com> wrote:
-- Yeah, but you could have used the way we do for parallel query where
we setup dsm and share all such information. You can check the logic
of execparallel.c and parallel.c to see how we do all such stuff for
parallel query.
Parallel query has a very clearly scoped lifetime, which seems to help. The parallel workers are started by a leader, whose lifetime entirely encompasses that of the workers. They're strictly children of the leader process.
In logical replication, the logical replication manager doesn't start the walsenders, they're started by the postmaster in response to inbound connections.
But the logical replication launcher does start the managers, and the managers start the apply workers. (IIRC). If we don't mind the whole thing dying and restarting if the launcher dies, or workers for a db dying if a database manager dies, then using dsm segments and detach notifications does seem viable.
IIRC when we did something similar in pglogical we ran into problems with (a) inability to handle an ERROR in a bgworker without exiting and being restarted by the postmaster; and (b) the postmaster remembering bgworker registrations across crash restart with no way to tell it not to. Maybe Petr remembers the details?
В списке pgsql-hackers по дате отправления: