Обсуждение: Re: [HACKERS] Interval for launching the table sync worker
On Thu, Apr 06, 2017 at 11:33:22AM +0900, Masahiko Sawada wrote: > While testing table sync worker for logical replication I noticed that > if the table sync worker of logical replication failed to insert the > data for whatever reason, the table sync worker process exits with > error. And then the main apply worker launches the table sync worker > again soon without interval. This routine is executed at very high > frequency without interval. > > Should we do put a interval (wal_retrieve_interval or make a new GUC > parameter?) for launching the table sync worker? [Action required within three days. This is a generic notification.] The above-described topic is currently a PostgreSQL 10 open item. Peter, since you committed the patch believed to have created it, you own this open item. If some other commit is more relevant or if this does not belong as a v10 open item, please let us know. Otherwise, please observe the policy on open item ownership[1] and send a status update within three calendar days of this message. Include a date for your subsequent status update. Testers may discover new open items at any time, and I want to plan to get them all fixed well in advance of shipping v10. Consequently, I will appreciate your efforts toward speedy resolution. Thanks. [1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com
On Sun, Apr 16, 2017 at 06:08:41AM +0000, Noah Misch wrote: > On Thu, Apr 06, 2017 at 11:33:22AM +0900, Masahiko Sawada wrote: > > While testing table sync worker for logical replication I noticed that > > if the table sync worker of logical replication failed to insert the > > data for whatever reason, the table sync worker process exits with > > error. And then the main apply worker launches the table sync worker > > again soon without interval. This routine is executed at very high > > frequency without interval. > > > > Should we do put a interval (wal_retrieve_interval or make a new GUC > > parameter?) for launching the table sync worker? > > [Action required within three days. This is a generic notification.] > > The above-described topic is currently a PostgreSQL 10 open item. Peter, > since you committed the patch believed to have created it, you own this open > item. If some other commit is more relevant or if this does not belong as a > v10 open item, please let us know. Otherwise, please observe the policy on > open item ownership[1] and send a status update within three calendar days of > this message. Include a date for your subsequent status update. Testers may > discover new open items at any time, and I want to plan to get them all fixed > well in advance of shipping v10. Consequently, I will appreciate your efforts > toward speedy resolution. Thanks. > > [1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com This PostgreSQL 10 open item is past due for your status update. Kindly send a status update within 24 hours, and include a date for your subsequent status update. Refer to the policy on open item ownership: https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com
On 4/19/17 23:02, Noah Misch wrote: > This PostgreSQL 10 open item is past due for your status update. Kindly send > a status update within 24 hours, and include a date for your subsequent status > update. Refer to the policy on open item ownership: > https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com This is currently on the back burner relative to other issues. Next check-in from me by Monday. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 4/20/17 15:36, Peter Eisentraut wrote: > On 4/19/17 23:02, Noah Misch wrote: >> This PostgreSQL 10 open item is past due for your status update. Kindly send >> a status update within 24 hours, and include a date for your subsequent status >> update. Refer to the policy on open item ownership: >> https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com > > This is currently on the back burner relative to other issues. Next > check-in from me by Monday. Update: I think there are some light disagreements about whether to go for a simple localized patch or a more extensive rework. If the latter camp doesn't convince me, I'll commit the former solution by Friday. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services