| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: segmentation fault using currtid and partitioned tables |
| Date: | 2020-06-01 02:26:54 |
| Message-ID: | 11083.1590978414@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2020-06-01 03:35:59 | Re: Compatible defaults for LEAD/LAG |
| Previous Message | Michael Paquier | 2020-06-01 02:20:55 | Re: segmentation fault using currtid and partitioned tables |