From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | petr(dot)jelinek(at)2ndquadrant(dot)com |
Cc: | masao(dot)fujii(at)gmail(dot)com, sawada(dot)mshk(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: some review comments on logical rep code |
Date: | 2017-04-21 04:27:56 |
Message-ID: | 20170421.132756.83148938.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Wed, 19 Apr 2017 10:59:00 +0200, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> wrote in <3ef9c831-0508-51a9-5ded-c2e31e958a9f(at)2ndquadrant(dot)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(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20170419(dot)174317(dot)114509231(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> >> At Wed, 19 Apr 2017 10:33:29 +0200, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> wrote in <ed73a706-9e15-f137-2d55-f05361f2de9a(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2017-04-21 05:34:57 | Re: Quorum commit for multiple synchronous replication. |
Previous Message | Masahiko Sawada | 2017-04-21 04:20:05 | Re: Quorum commit for multiple synchronous replication. |