At Thu, 1 Dec 2022 19:23:28 -0800, Andres Freund <andres@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
