Re: Potential ABI breakage in upcoming minor releases

Hi,

> > src/ts_catalog/catalog.c-extern TSDLLEXPORT ResultRelInfo *
> > src/ts_catalog/catalog.c-ts_catalog_open_indexes(Relation heapRel)
> > src/ts_catalog/catalog.c-{
> > src/ts_catalog/catalog.c-   ResultRelInfo *resultRelInfo;
> > src/ts_catalog/catalog.c-
> > src/ts_catalog/catalog.c:   resultRelInfo = makeNode(ResultRelInfo);
> > src/ts_catalog/catalog.c-   resultRelInfo->ri_RangeTableIndex = 0; /* dummy */
> > src/ts_catalog/catalog.c-   resultRelInfo->ri_RelationDesc = heapRel;
> > src/ts_catalog/catalog.c-   resultRelInfo->ri_TrigDesc = NULL; /* we don't fire triggers */
> > src/ts_catalog/catalog.c-
> > src/ts_catalog/catalog.c-   ExecOpenIndices(resultRelInfo, false);
>
> This is a copy of PostgreSQL's CatalogOpenIndexes().  Assuming timescaledb
> uses it like PostgreSQL uses CatalogOpenIndexes(), it's fine.  Specifically,
> CatalogOpenIndexes() is fine since PostgreSQL does not pass the ResultRelInfo
> to ModifyTable.

Yes. Initially I thought this was done for compatibility reasons with
different PG versions, but this doesn't seem to be the case since
CatalogOpenIndexes() was in the core for a long time.

> > Oh, hmm, there's this bit which uses struct assignment into a stack
> > element:
>
> Yes, stack allocation of a ResultRelInfo sounds relevant to the crash.  It
> qualifies as a "very unusual code pattern" in the postgr.es/c/e54a42a sense.

Yes, this is another issue.

I'm working with the TimescaleDB dev team to fix these issues on the
TimescaleDB side.

-- 
Best regards,
Aleksander Alekseev