| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Hadi Moshayedi <hadi(at)moshayedi(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: REL_12_STABLE crashing with assertion failure in ExtractReplicaIdentity |
| Date: | 2019-09-02 20:49:15 |
| Message-ID: | 14590.1567457355@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> I agree that it ought to be more efficent - but also about as equally
> safe? I.e. if the previous code wasn't safe, the new code wouldn't be
> safe either? As in, we're "just" avoiding the assert, but not increasing
> safety?
Well, the point is that the old code risks performing a relcache load
without holding any lock on the relation. In practice, given that
we do hold a lock on the parent table, it's probably safe ... but
it's at best bad practice. It's not too hard to imagine future
optimizations that would allow this to result in a corrupt relcache entry.
I don't believe that there's any equivalent risk in the modified code.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2019-09-02 21:15:00 | Re: [HACKERS] WAL logging problem in 9.4.3? |
| Previous Message | Andres Freund | 2019-09-02 20:39:51 | Re: REL_12_STABLE crashing with assertion failure in ExtractReplicaIdentity |