Alvaro Herrera wrote:
> Correct. The only difficulty here is that we would need to pass down
> the fact that we know for certain that this is only a locking Multixact.
> There are some callers that go to it indirectly via MultiXactIdWait or
> MultiXactIdExpand, but now that I look I think it's fine for those to
> pass false (i.e. assume there might be an update and disable the
> optimization), since those aren't hot compared to the other cases.
>
> This patch implements this idea, but I haven't tested it much beyond
> compiling and ensuring it passes the existing tests.
.. and it turns out it doesn't work. To be really effective, we need
MultiXactIdIsRunning to be passed down the flag too, so it can pass it
to GetMultiXactIdMembers.
One other thought is that MultiXactIdIsRunning and GetMultiXactIdMembers
are public functions, so this patch would represent an API change in
9.3. I doubt any external modules would be relying on these functions,
but there's so many care and thought put into avoiding API changes on
released versions that I'm nervous about doing it here. So I think we'd
need to provide a compatibility shim to avoid that.
(I generally dislike to keep compatibility stuff forever, so I would
provide this backward-compatible functions in 9.3 only. Anyone using it
would have to fix the code and recompile for 9.4+. This means a #ifdef
in code meant to work on top of both 9.3 and 9.4. Anyone opines
otherwise?)
The other idea is to just not backpatch this.
Other than that, this patch implements the optimization suggested here.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
