At Wed, 19 Apr 2017 10:59:00 +0200, Petr Jelinek <petr.jeli...@2ndquadrant.com> wrote in <3ef9c831-0508-51a9-5ded-c2e31e958...@2ndquadrant.com> > On 19/04/17 10:45, Kyotaro HORIGUCHI wrote: > > 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> > >> 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. > > > > Yeah but I think that's risk anyway in MVCC read committed database, the > only way to protect against that would be to hold lock over the catalogs > access which was what we wanted to get rid of :)
Agreed, or, I'm not sure about the real risks. > BTW the whole sync coordination is explicitly written in a way that > unless you mess with catalogs manually only the tablesync process should > do UPDATEs to that catalog (with the exception of s->r state switch > which can happen in apply and has no effect on sync because both states > mean that synchronization is done, only makes apply stop tracking the > table individually). Hmm. Inhibiting retrospective updates of the on-memory data would save from some kind of priority inversions but such kind of manual operation is similar to overwriting of pg_control and I think is not worth bothering about:p 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
