Date: Fri, 20 Sep 2019 09:16:58 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Nikolay Shaplov <dhyan@nataraj.su>
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
Message-ID: <20190920001658.GA1844@paquier.xyz>
References: <17071942.m9zZutALE6@x200m>
 <CA+hUKG+8294zbN_k=QDgcW2TFia5TqsTR8nJLyYU+_C8vUTmrg@mail.gmail.com>
 <20190919083203.GC21144@paquier.xyz>
 <6059120.LlfbHtIvrV@x200m>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY"
Content-Disposition: inline
In-Reply-To: <6059120.LlfbHtIvrV@x200m>
Precedence: bulk


--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 19, 2019 at 02:13:23PM +0300, Nikolay Shaplov wrote:
> What a good catch! dummy_index already proved to be useful ;-)

Yes, the testing around custom reloptions is rather poor now, so this
module has value.  I still don't like much its shape though, so I
began hacking on it for integration, and I wanted to get that part
down in this CF :)

There may be other issues, but let's sort out that later if anything
shows up.

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

I guess so, but with table AMs introduced in 12, I would suspect that
we are going to have much more use cases popping out, and that these
use cases would be very happy to have the possibility to lower the
lock level needed to set a custom reloption.  I would like to get that
fixed and back-patched separately.  As it is not especially clear for
everybody here in a thread dedicated to a test module that we are
discussing about a backend-side bug, I am going to spawn a new thread
with a proper patch.  Perhaps I missed something as well, so it would
be good to get more input on that.

> As you know I have plans for rewriting options engine and there would be =
same=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 reac=
h=20
> 13...

Well, another thing would be to extend the existing routines so as
they take an extra argument to be able to enforce the lockmode, which
is something that can be done without a large rewrite of the whole
facility, and the change is less invasive so it would have better
chances to get into core.  I don't mind changing those APIs on HEAD by
the way as long as the breakage involves a clean compilation failure
and I don't think they are the most popular extension APIs ever.
Perhaps others don't have the same line of thoughts, but let's see.
--
Michael

--OXfL5xGRrasGEqWY
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAl2EGnoACgkQnvQgOdby
QH1c0A//Q3AcW9G6WaIbsg6yt+qwfOFTuUcmPtvnfQma9IdXGzDF0QDUqdWTAoA7
W76IdZNsqWINzrHcSCI9hFwm1amFGNJ365tWPXchxyEI18IS6BdDIbWLq+uDZOkN
A9gxJPxLIOKGDTKWHauMePkMwLE055PfgmsKPiQwQXNMH2SM021kb34sMUJ+UoLC
U5V3G0E66JXj4pK2ZD31cK7sYRvXk3NNG2UL2MAjNhnv9+SVe9tQsf1a0o0dv39r
PtO9f0cXPN+bBjVYc0xYuJBqX6mcKqzQAqEDN7ChvXU/h90Xlw+7ayGIPHKl1kLG
R/nMr87/KqUz3dv35V4oxXunZRxjG3KQOihTkftB6npEQNO4BWQPDRH2I5qBV+uB
JkaTEHU42XbxtCjRL7Wz4k34feVmnLcNW87v4tYtk65LCznrdmm8KXAqliOiM+by
3u3ED8K4t1wOSmwg2XSSxArA8AmCTIkVNRKS4MLNpGP8DqQTJwu/R/LMkazwksel
Y3CbOd45nr3KNS8A/Tf2QQsC1s1RO/YL2RB57aS9iVzzpMizRfjvcZN4DXZKmja6
53CA93hL5EHd6ov2DZmea0r1rQPQu5p+z968P9RiSUvjDKfDsDpTH5EGmLhci16f
5SRGYNl8ywFcAe0YPemKZFHgFSHOJoZyu8Sk1glphrBWd1H8gdQ=
=9JAn
-----END PGP SIGNATURE-----

--OXfL5xGRrasGEqWY--