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

From Andres Freund
Subject Re: segmentation fault using currtid and partitioned tables
Date
Msg-id 20200529010506.dgnmocw7hdbldtrh@alap3.anarazel.de
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
List pgsql-hackers
Hi,

On 2020-04-05 12:51:56 -0400, Tom Lane wrote:
> (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.

I don't have particularly strong views here. I can see a benefit to such
a pseudo AM. I can even imagine that there might some cases where we
would actually introduce some tableam functions for e.g. partitioned or
views tables, to centralize their handling more, instead of having such
considerations more distributed.  Clearly not worth actively trying to
do that for all existing code dealing with such relkinds, but there
might be cases where it's worthwhile.

OTOH, it's kinda annoying having to maintain a not insignificant number
of functions that needs to be updated whenever the tableam interface
evolves.  I guess we could partially hack our way through that by having
one such function, and just assigning it to all the mandatory callbacks
by way of a void cast. But that'd be mighty ugly.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond.
Next
From: Andy Fan
Date:
Subject: Re: Make the qual cost on index Filter slightly higher than qual coston index Cond.