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

From Michael Paquier
Subject Re: segmentation fault using currtid and partitioned tables
Date
Msg-id 20200408071331.GI1606@paquier.xyz
Whole thread Raw
In response to Re: segmentation fault using currtid and partitioned tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: segmentation fault using currtid and partitioned tables  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Sun, Apr 05, 2020 at 12:51:56PM -0400, Tom Lane wrote:
> 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.

Yeah, that's not good, but I am not really comfortable with the
concept of implying that (pg_class.relam == InvalidOid) maps to a
dummy AM callback set instead of NULL for rd_tableam.  That feels less
natural.  As mentioned upthread, the error that we get in ~11 is
confusing as well when using a relation that has no storage:
ERROR:  58P01: could not open file "base/16384/16385": No such file or directory

I have been looking at the tree and the use of the table AM APIs, and
those TID lookups are really a particular case compared to the other
callers of the table AM callbacks.  Anyway, I have not spotted similar
problems, so I find very tempting the option to just add some
RELKIND_HAS_STORAGE() to tid.c where it matters and call it a day.

Andres, what do you think?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: pg_stat_statements issue with parallel maintenance (Was Re: WALusage calculation patch)
Next
From: Masahiko Sawada
Date:
Subject: Re: doc review for parallel vacuum