On Fri, Feb 2, 2018 at 12:31 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Jan 31, 2018 at 7:37 PM, Masahiko Sawada <sawada.m...@gmail.com> > wrote: >> I think the idea would not be an improvement, but just change the >> policy. The current launcher's policy is "let's launch a new worker as >> much as possible on the database that is at risk of wraparound most". >> The idea I suggested makes the cases mentioned on this thread better >> while perhaps making other cases worse. >> >> To improve while keeping the current policy, we might want to use the >> first idea I proposed. That is, we don't launch a new worker on a >> database impending wraparound if the last table of the database is >> being vacuumed. But it needs to share new information such as what >> tables exist in each database and which tables already have worker. It >> might be overkill in order to deal with only such a corner case >> though. > > Something like that might work, but I think it needs more thought. > Maybe, for each database currently being processed by at least 1 > worker, advertise in shared memory the oldest XID that isn't already > being vacuumed by some AV worker; when considering which database is > at greatest risk of wraparound, if that value is available, use it > instead of the database's datfrozenxid. Then when all tables that > make that database riskier than some other database already have > workers, some other database can get a chance. >
Thank you for suggestion. It sounds more smarter. So it would be more better if we vacuums database for anti-wraparound in ascending order of relfrozenxid? Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
