Re: [HACKERS] WAL logging problem in 9.4.3?

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 <noah(at)leadboat(dot)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