Re: BUG #15114: logical decoding Segmentation fault - Mailing list pgsql-bugs

From Kyotaro HORIGUCHI
Subject Re: BUG #15114: logical decoding Segmentation fault
Date
Msg-id 20181119.184916.179764314.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: BUG #15114: logical decoding Segmentation fault  (Michael Paquier <michael@paquier.xyz>)
Responses Re: BUG #15114: logical decoding Segmentation fault
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #15511: Drop table error "invalid argument"
Next
From: PG Bug reporting form
Date:
Subject: BUG #15512: Creating index on 119 M files table generates error[could not determine size of temporary file "0"]