At Wed, 19 Apr 2017 17:43:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote in <20170419.174317.114509231.horiguchi.kyot...@lab.ntt.co.jp> > At Wed, 19 Apr 2017 10:33:29 +0200, Petr Jelinek > <petr.jeli...@2ndquadrant.com> wrote in > <ed73a706-9e15-f137-2d55-f05361f2d...@2ndquadrant.com> > > > Commit has been moved from after to before of the lock section. > > > This causes potential race condition. (As the same as the > > > potential dead-lock, I'm not sure it can cause realistic problem, > > > though..) Isn't it better to be after the lock section? > > > > > > > We just read catalogs so there should not be locking issues. > > Some other process may modify it then go to there. With a kind of > priority inversion, the process may modify the data on the memory > *before* we modify it. Of course this is rather unrealistic, > though.
A bit short. Some other process may modify it *after* we read it then go to there. With a kind of priority inversion, the process may modify the data on the memory *before* we modify it. Of course this is rather unrealistic, though. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
