At Thu, 1 Dec 2022 19:23:28 -0800, Andres Freund <and...@anarazel.de> wrote in > > AtEOXact_PgStat_DroppedStats() visits a relation that has been dropped > > then wiped (when CLOBBER_FREED_MEMORY) by AtEOXact_RelationCache() > > called just before. Since the relcache content directly pointed from > > stats module is lost in this case, the stats side cannot defend itself > > from this. > > > > Perhaps RelationDestroyRelation() need to do pgstat_drop_entry() or > > AtEOXact_PgStat_DroppedStats() should be called before > > AtEOXact_RelationCache(). the latter of which is simpler. I think we > > need to test this case, too. > > This doesn't strike me as the right fix. What do you think about my patch at > https://postgr.es/m/20221128210908.hyffmljjylj447nu%40awork3.anarazel.de , > leaving the quibbles around error handling aside?
Yeah, I didn't like what my patch does... > Afaict it fixes the issue. Hmm. I see it works for this specific case, but I don't understand why it is generally safe. The in-xact created relation t1 happened to be scanned during the CREATE RULE and a stats entry is attached. So the stats entry loses t1 at roll-back, then crashes. Thus, if I understand it correctly, it seems to me that just unlinking the stats from t1 (when relkind is changed) works. But the fix doesn't change the behavior in relkind-not-changing cases. If an in-xact-created table gets a stats entry then the relcache entry for t1 is refreshed to a table relation again then the transaction rolls back, crash will happen for the same reason. I'm not sure if there is such a case actually. When I tried to check that behavior further, I found that that CREATE ROLE is no longer allowed.. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
