Re: segmentation fault using currtid and partitioned tables
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jaime Casanova <jaime.casanova@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>
Date: 2020-04-08T07:13:31Z
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
Commits
-
Fix use-after-release mistake in currtid() and currtid2() for views
- a8c6eb5b4c4c 9.5.23 landed
- e2fa9732fddc 9.6.19 landed
- a36f216209b8 10.14 landed
- 8bc74490df25 11.9 landed
- 894041eb262f 12.4 landed
- ce1c5b9ae87b 13.0 landed
-
Fix crashes with currtid() and currtid2()
- 95e389b3c2ea 12.4 landed
- e786be5fcb25 13.0 landed