Oops. I played on a wrong branch and got stuck in slow build on Windows... At Tue, 18 Feb 2020 00:53:37 -0800, Noah Misch <n...@leadboat.com> wrote in > On Tue, Feb 18, 2020 at 03:56:15PM +1300, Thomas Munro wrote: > > CREATE TYPE priv_testtype1 AS (a int, b text); > > +ERROR: relation 24844 deleted while still in use > > REVOKE USAGE ON TYPE priv_testtype1 FROM PUBLIC; > > > > https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.79923 > > > > It didn't fail on the same OS a couple of days earlier: > > > > https://ci.appveyor.com/project/postgresql-cfbot/postgresql/builds/30829686 > > Thanks for the report. This reproduces consistently under > CLOBBER_CACHE_ALWAYS (which, coincidentally, I started today). Removing the > heap_create() change fixes it. Since we now restore a saved rd_createSubid, > the heap_create() change is obsolete. My next version will include that fix.
Yes, ATExecAddIndex correctly set createSubid without that. > The system uses rd_createSubid to mean two things. First, rd_node is new. > Second, the rel might not yet be in catalogs, so we can't rebuild its relcache > entry. The first can be false while the second is true, hence this failure. > However, the second is true in a relatively-narrow period in which we don't > run arbitrary user code. Hence, that simple fix suffices. I didn't care the second meaning. I thought it is caused by invalidation but I couldn't get a core dump on Windows 10.. The comment for RelationCacheInvalidate seems faintly explains about the second meaning. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
