Re: BUG #15114: logical decoding Segmentation fault

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: michael(at)paquier(dot)xyz
Cc: andres(at)anarazel(dot)de, petr(dot)jelinek(at)2ndquadrant(dot)com, pet(dot)slavov(at)gmail(dot)com, alvherre(at)alvh(dot)no-ip(dot)org, petr(at)2ndquadrant(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, peter(dot)eisentraut(at)2ndquadrant(dot)com
Subject: Re: BUG #15114: logical decoding Segmentation fault
Date: 2018-11-19 09:49:16
Message-ID: 20181119.184916.179764314.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

At Wed, 31 Oct 2018 16:29:38 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in <20181031072938(dot)GC7862(at)paquier(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2018-11-19 11:05:56 BUG #15512: Creating index on 119 M files table generates error [could not determine size of temporary file "0"]
Previous Message Etsuro Fujita 2018-11-19 04:05:43 Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT