Re: BUG #15114: logical decoding Segmentation fault

Hi,

On 2018-03-15 23:55:32 +0100, Петър Славов wrote:
> #0  GetActiveSnapshot () at
> /build/postgresql-10-drhiey/postgresql-10-10.3/build/../src/backend/utils/time/snapmgr.c:843
> #1  0x00005649b753e928 in postquel_start (fcache=0x5649b89b7968,
2
> /build/postgresql-10-drhiey/postgresql-10-10.3/build/../src/backend/optimizer/util/clauses.c:2437
> #13 0x00005649b777181a in RelationGetIndexPredicate
> (relation=relation@entry=0x7f76e7841568)
> at
> /build/postgresql-10-drhiey/postgresql-10-10.3/build/../src/backend/utils/cache/relcache.c:4813
> #14 0x00005649b7443d60 in BuildIndexInfo (index=index@entry=0x7f76e7841568)
> at
> /build/postgresql-10-drhiey/postgresql-10-10.3/build/../src/backend/catalog/index.c:1660
> #15 0x00005649b7771b90 in RelationGetIndexAttrBitmap
> (relation=relation@entry=0x7f76e7836638,
> attrKind=attrKind@entry=INDEX_ATTR_BITMAP_IDENTITY_KEY)
> at
> /build/postgresql-10-drhiey/postgresql-10-10.3/build/../src/backend/utils/cache/relcache.c:4938
> #16 0x00005649b7614368 in logicalrep_write_attrs (rel=0x7f76e7836638,
> out=0x5649b88dee38) at
> /build/postgresql-10-drhiey/postgresql-10-10.3/build/../src/backend/replication/logical/proto.c:530
> #17 logicalrep_write_rel (out=0x5649b88dee38, rel=0x7f76e7836638) at
> /build/postgresql-10-drhiey/postgresql-10-10.3/build/../src/backend/replication/logical/proto.c:317
> #18 0x00007f76998b5e6f in pgoutput_change (ctx=<optimized out>,
> txn=<optimized out>, relation=0x7f76e7836638, change=0x5649b899b1f8) at
> /build/postgresql-10-drhiey/postgresql-10-10.3/build/../src/backend/replication/pgoutput/pgoutput.c:324
> #19 0x00005649b760fbc9 in change_cb_wrapper (cache=<optimized out>,
> txn=<optimized out>, relation=<optimized out>, change=<optimized out>) at
> /build/postgresql-10-drhiey/postgresql-10-10.3/build/../src/backend/replication/logical/logical.c:711

Alvaro, Petr: If I understand correctly what happens here is that some
*other* column than the replica identity has a predicate with a full
blown SQL function.  We shouldn't evaluate arbitrary code like that
inside the otuput plugin!

So RelationGetIndexAttrBitmap() builds a bitmap of *all* indexed
columns. Besides the code exec problem above, this is also just
inefficient.  I think this needs to be replaced by some replident
bespoke code?

Greetings,

Andres Freund