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
> 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
> options code both for core Access Methods and for options for AM from
> 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
> 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