Re: BUG #15114: logical decoding Segmentation fault
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: BUG #15114: logical decoding Segmentation fault |
Дата | |
Msg-id | 20181119.184916.179764314.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: BUG #15114: logical decoding Segmentation fault (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: BUG #15114: logical decoding Segmentation fault
|
Список | pgsql-bugs |
At Wed, 31 Oct 2018 16:29:38 +0900, Michael Paquier <michael@paquier.xyz> wrote in <20181031072938.GC7862@paquier.xyz> > On Tue, Oct 30, 2018 at 04:09:31PM -0700, Andres Freund wrote: > > Replication needs to maintain the other indexes, and for that it needs > > to evaluate predicates. So I don't understand how you could say that > > it doesn't need to know about other indexes? > > You are right, sorry for the noise. The worker applies the changes so > it needs to know about all the indexes and its information. So we need > to tackle three separate issues here then: > 1) On the sender side, make sure that only the replica index information > is fetched. I actually would prefer something like what Alvaro proposed > upthread, to not save the saved information into the cached Relation, > and potentially have RelationGetIndexAttrBitmap() overwrite it. +1. We won't reuse it elsewhere, and we don't build other bitmaps there. > 2) On the apply side, move the snapshot build a bit earlier so as the > index information can be built properly. Subscriber crashes without it and fixed with it. > 3) Make sure that RelationGetIndexAttrBitmap() never gets called if > there is no snapshot available. I'm not sure putting assertion into only the place is reasonable. BuildIndexInfo has the same hazard and will catch the similar cases widely. > 1) and 2) are the actual bug fixes to back-patch. 3) is optionally > something for HEAD, which Petr proposed. Agreed. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-bugs по дате отправления: