Re: BUG #15114: logical decoding Segmentation fault

On Sun, Oct 28, 2018 at 11:59:49PM +0100, Petr Jelinek wrote:
> I wrote my own patch to solve this which is quite similar to Alvaro's
> except that it does not do the manual work to build indexes list as we
> already have RelationGetReplicaIndex which does all the necessary work
> and also uses the same rd_idattr for cache that
> RelationGetIndexAttrBitmap does, it's better for performance and looks
> safe to me.
>
> I attached both patch for PG11+ (ie master) and the backport patch for
> PG10, they only differ in the line identified above as problematic.

Hmm.  I am studying this patch, and this visibly cannot be easily
reproduced?  I would have imagined that something like this would be
enough, with a predicate index on the publisher side which is in charge
of loading the :
-- connect to publisher
\c postgres postgres /tmp 5432
create table aa (a int not null, b int);
create function copy_int(a int) returns int as $$ select $1 $$
  language sql immutable;
create index aai on aa (b) where copy_int(b) > 0;
create unique index aai2 on aa (a);
alter table aa replica identity using index aai2;
create publication big_tables for table aa;
insert into aa values (generate_series(1,100), 1);

-- connect to subscriber
\c postgres postgres /tmp 5433
create table aa (a int not null, b int);
create function copy_int(a int) returns int as $$ select $1 $$
  language sql immutable;
create index aai on aa (b) where copy_int(b) > 0;
create unique index aai2 on aa (a);
alter table aa replica identity using index aai2;
create subscription sub_name CONNECTION 'host=/tmp dbname=postgres
user=postgres' PUBLICATION big_tables;

Is there something I am missing?

If possible, could it be possible to add a test case in
001_rep_changes.pl with a more complete schema?
--
Michael