Re: segmentation fault using currtid and partitioned tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: segmentation fault using currtid and partitioned tables
Date
Msg-id 14846.1586105516@sss.pgh.pa.us
Whole thread Raw
In response to segmentation fault using currtid and partitioned tables  (Jaime Casanova <jaime.casanova@2ndquadrant.com>)
Responses Re: segmentation fault using currtid and partitioned tables  (Michael Paquier <michael@paquier.xyz>)
Re: segmentation fault using currtid and partitioned tables  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Jaime Casanova <jaime.casanova@2ndquadrant.com> writes:
> Another one caught by sqlsmith, on the regression database run this
> query (using any non-partitioned table works fine):
> select currtid('pagg_tab'::regclass::oid, '(0,156)'::tid) >= '(1,158)'::tid;

Hm, so

(1) currtid_byreloid and currtid_byrelname lack any check to see
if they're dealing with a relkind that lacks storage.

(2) The proximate cause of the crash is that rd_tableam is zero,
so that the interface functions in tableam.h just crash hard.
This seems like a pretty bad thing; does anyone want to promise
that there are no other oversights of the same ilk elsewhere,
and never will be?

I think it might be a good idea to make relations-without-storage
set up rd_tableam as a vector of dummy functions that will throw
some suitable complaint about "relation lacks storage".  NULL is
a horrible default for this.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: SQL/JSON: functions
Next
From: Tomas Vondra
Date:
Subject: Re: WIP: BRIN multi-range indexes