From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: segmentation fault using currtid and partitioned tables |
Date: | 2020-04-08 07:13:31 |
Message-ID: | 20200408071331.GI1606@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2020-04-08 07:19:11 | Re: doc review for parallel vacuum |
Previous Message | Julien Rouhaud | 2020-04-08 07:11:41 | Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch) |