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-19T12:33:56Z
Lists: pgsql-hackers
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. -- 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