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
