Re: segmentation fault using currtid and partitioned tables
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Jaime Casanova <jaime.casanova@2ndquadrant.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2020-06-01T02:26:54Z
Lists: pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes: > Woah. This one is old, good catch from -DRELCACHE_FORCE_RELEASE. It > happens that since its introduction in a3519a2 from 2002, > currtid_for_view() in tid.c closes the view and then looks at a RTE > from it. I have reproduced the issue and the patch attached takes > care of the problem. Would it be better to backpatch all the way down > or is that not worth caring about? Ugh. Aside from the stale-pointer-deref problem, once we drop the lock we can't even be sure the table still exists. +1 for back-patch. regards, tom lane
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