Re: src/test/subscription/t/002_types.pl hanging on particular environment
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Thomas Munro <thomas.munro@enterprisedb.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-09-19T13:08:33Z
Lists: pgsql-hackers
On Tue, Sep 19, 2017 at 6:29 PM, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote: > On 19/09/17 14:33, Amit Kapila wrote: >> On Tue, Sep 19, 2017 at 3:34 PM, Petr Jelinek >> <petr.jelinek@2ndquadrant.com> wrote: >>> n 18/09/17 18:42, Tom Lane wrote: >>> >>>> So, frankly, I think we would be best off losing the "logical rep >>>> worker slot" business altogether, and making do with just bgworker >>>> slots. >> >> I think that would be cleaner as compared to what we have now. >> >>>> The alternative is getting the postmaster involved in cleaning >>>> up lrep slots as well as bgworker slots, and I'm going to resist >>>> any such idea strongly. That way madness lies, or at least an >>>> unreliable postmaster --- if we need lrep slots, what other forty-seven >>>> data structures are we going to need the postmaster to clean up >>>> in the future? >>>> >>>> I haven't studied the code enough to know why it grew lrep worker >>>> slots in the first place. Maybe someone could explain? >>>> >>> >>> I am not quite sure I understand this question, we need to store >>> additional info about workers in shared memory so we need slots for that. >>> >> >> 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. >> > > I don't understand how DSM helps in this case (except perhaps the memory > allocation being dynamic rather than static). We still need this shared > memory area to be accessible from other places than launcher (the > paralllel query has one lead which manages everything, that's not true > for logical replication) > I am not much aware of this area. Can you explain what other usages it has apart from in the process that has launched the worker and in worker itself? > and we need it to survive restart of launcher > for example, so all the current issues will stay. > Do you mean to say that you want to save this part of shared memory across restart of launcher? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Fix, or at least ameliorate, bugs in logicalrep_worker_launch().
- c1bde0747983 10.0 landed
- 3e1683d37e1d 11.0 landed
-
Fix DROP SUBSCRIPTION hang
- 8edacab20995 11.0 cited