From: Nikolay Shaplov <dhyan@nataraj.su>
To: Michael Paquier <michael@paquier.xyz>
Cc: Thomas Munro <thomas.munro@gmail.com>, Dent John <denty@qqdd.eu>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Alvaro Herrera <alvherre@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 Robert Haas <robertmhaas@gmail.com>
Subject: Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions
 from inside of access method
Date: Thu, 19 Sep 2019 14:13:23 +0300
Message-ID: <6059120.LlfbHtIvrV@x200m>
User-Agent: KMail/5.2.3 (Linux/4.9.0-8-amd64; KDE/5.28.0; x86_64; ; )
In-Reply-To: <20190919083203.GC21144@paquier.xyz>
References: <17071942.m9zZutALE6@x200m>
 <CA+hUKG+8294zbN_k=QDgcW2TFia5TqsTR8nJLyYU+_C8vUTmrg@mail.gmail.com>
 <20190919083203.GC21144@paquier.xyz>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

=D0=92 =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0=B5 =D0=BE=D1=82 =D1=87=D0=B5=D1=82=
=D0=B2=D0=B5=D1=80=D0=B3, 19 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=
=8F 2019 =D0=B3. 17:32:03 MSK =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=
=B0=D1=82=D0=B5=D0=BB=D1=8C Michael=20
Paquier =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

> > src/test/modules/dummy_index_am directory check" I see a similar
> > failure with "ERROR:  unrecognized lock mode: 2139062143".  I changed
>=20
> > that to a PANIC and got a core file containing this stack:
> A simple make check on the module reproduces the failure, so that's
> hard to miss.
=46or some reason it does not reproduce on my dev environment, but it not r=
eally=20
important, since the core of the problem is found.
>=20
> From what I can see it is not a problem caused directly by this
> module, specifically knowing that this test module is actually copying
> what bloom is doing when declaring its reloptions.  Take this example:
> CREATE EXTENSION bloom;
> CREATE TABLE tbloom AS
>     SELECT
>       (random() * 1000000)::int as i1,
>       (random() * 1000000)::int as i2,
>       (random() * 1000000)::int as i3,
>       (random() * 1000000)::int as i4,
>       (random() * 1000000)::int as i5,
>       (random() * 1000000)::int as i6
>     FROM
>    generate_series(1,100);
> CREATE INDEX bloomidx ON tbloom USING bloom (i1,i2,i3)
>        WITH (length=3D80, col1=3D2, col2=3D2, col3=3D4);
> ALTER INDEX bloomidx SET (length=3D100);
>=20
> And then you get that:
> ERROR:  XX000: unrecognized lock mode: 2139062143
> LOCATION:  LockAcquireExtended, lock.c:756
>=20
> So the options are registered in the relOpts array managed by
> reloptions.c but the data is not properly initialized.  Hence when
> looking at the lock needed we have an option match, but the lock
> number is incorrect, causing the failure.  It looks like there is no
> direct way to enforce the lockmode used for a reloption added via
> add_int_reloption which does the allocation to add the option to
> add_reloption(), but enforcing the value to be initialized fixes the
> issue:
> --- a/src/backend/access/common/reloptions.c
> +++ b/src/backend/access/common/reloptions.c
> @@ -658,6 +658,7 @@ allocate_reloption(bits32 kinds, int type, const
> char *name, const char *desc)
>     newoption->kinds =3D kinds;
>     newoption->namelen =3D strlen(name);
>     newoption->type =3D type;
> +   newoption->lockmode =3D AccessExclusiveLock;
>     MemoryContextSwitchTo(oldcxt);

What a good catch! dummy_index already proved to be useful ;-)


> I would think that initializing that to a sane default is something
> that we should do anyway, or is there some trick allowing the
> manipulation of relOpts I am missing?=20

Yes I think AccessExclusiveLock is quite good default I think. Especially i=
n=20
the case when these options are not really used in real world ;-)

> Changing the relopts APIs in
> back-branches is a no-go of course, but we could improve that for
> 13~.

As you know I have plans for rewriting options engine and there would be sa=
me=20
options code both for core Access Methods and for options for AM from=20
extensions. So there would be API for setting lockmode...
But the way it is going right now, I am not sure it will reviewed to reach=
=20
13...


PS. Michael, who will submit this lock mode patch? Hope you will do it? It=
=20
should go separately from dummy_index for sure...