pgsql: Remove unused wait events.
Remove unused wait events.
Commit 464824323e introduced the wait events which were neither used by
that commit nor by follow-up commits for that work.
Author: Masahiro Ikeda
Backpatch-through: 14, where it was introduced
Discussion: /messages/by-id/ff077840-3ab2-04dd-bbe4-4f5dfd2ad481@oss.nttdata.com
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/671eb8f34404d24c8f16ae40e94becb38afd93bb
Modified Files
--------------
doc/src/sgml/monitoring.sgml | 16 ----------------
src/backend/utils/activity/wait_event.c | 12 ------------
src/include/utils/wait_event.h | 6 +-----
3 files changed, 1 insertion(+), 33 deletions(-)
On Wed, Oct 20, 2021 at 10:52 PM Amit Kapila <akapila@postgresql.org> wrote:
Remove unused wait events.
Commit 464824323e introduced the wait events which were neither used by
that commit nor by follow-up commits for that work.
This commit forces a recompile of every extension that knows about the
integer values assigned to the enums in WaitEventIO. I know of 2
extensions that are affected by this. I think that it should be
reverted in v14 and kept only in master.
--
Robert Haas
EDB: http://www.enterprisedb.com
Robert Haas <robertmhaas@gmail.com> writes:
On Wed, Oct 20, 2021 at 10:52 PM Amit Kapila <akapila@postgresql.org> wrote:
Remove unused wait events.
This commit forces a recompile of every extension that knows about the
integer values assigned to the enums in WaitEventIO. I know of 2
extensions that are affected by this. I think that it should be
reverted in v14 and kept only in master.
Um ... the removed symbols were at the end of the WaitEventIO enum,
so is there really an ABI break? I suppose if an extension contains
actual references to the removed symbols, it would fail to recompile,
which'd be annoying for a released branch.
On the whole, I agree that this patch had no business being committed
to v14.
regards, tom lane
On Mon, Oct 25, 2021 at 12:38 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Um ... the removed symbols were at the end of the WaitEventIO enum,
so is there really an ABI break? I suppose if an extension contains
actual references to the removed symbols, it would fail to recompile,
which'd be annoying for a released branch.
I think that you're right. I believe one of the two extensions I know
about hopes that values won't be renumbered or become invalid across
minor releases, and the other contains specific references to these
particular constants.
Now of course it is always arguable whether or not anything that some
extension is doing ought to be deemed an acceptable use of the
facilities provided by core, and how much stability ought to be
guaranteed. But while I agree it's good to remove unused stuff in the
master, it doesn't seem like we really need to back-patch it.
--
Robert Haas
EDB: http://www.enterprisedb.com
Robert Haas <robertmhaas@gmail.com> writes:
... But while I agree it's good to remove unused stuff in the
master, it doesn't seem like we really need to back-patch it.
Yeah, exactly. I don't see any benefit that's commensurate with
even a small risk of breaking extensions --- and apparently, in
this case that's not a risk but a certainty.
regards, tom lane
On 25 Oct 2021, at 19:18, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
... But while I agree it's good to remove unused stuff in the
master, it doesn't seem like we really need to back-patch it.Yeah, exactly. I don't see any benefit that's commensurate with
even a small risk of breaking extensions --- and apparently, in
this case that's not a risk but a certainty.
Since this will cause integer values to have different textual enum value
representations in 14 and 15+, do we want to skip two numbers by assigning the
next wait event the integer value of WAIT_EVENT_WAL_WRITE incremented by three?
Or enum integer reuse not something we guarantee against across major versions?
--
Daniel Gustafsson https://vmware.com/
Daniel Gustafsson <daniel@yesql.se> writes:
Since this will cause integer values to have different textual enum value
representations in 14 and 15+, do we want to skip two numbers by assigning the
next wait event the integer value of WAIT_EVENT_WAL_WRITE incremented by three?
Or enum integer reuse not something we guarantee against across major versions?
We require a recompile across major versions. I don't see a reason why
this particular enum needs more stability than any other one.
regards, tom lane
On 2021-10-25 13:39:44 -0400, Tom Lane wrote:
Daniel Gustafsson <daniel@yesql.se> writes:
Since this will cause integer values to have different textual enum value
representations in 14 and 15+, do we want to skip two numbers by assigning the
next wait event the integer value of WAIT_EVENT_WAL_WRITE incremented by three?
Or enum integer reuse not something we guarantee against across major versions?We require a recompile across major versions. I don't see a reason why
this particular enum needs more stability than any other one.
+1. That'd end up pushing us to be more conservative about defining new wait
events, which I think would be bad tradeoff.
On 25 Oct 2021, at 20:01, Andres Freund <andres@anarazel.de> wrote:
On 2021-10-25 13:39:44 -0400, Tom Lane wrote:
Daniel Gustafsson <daniel@yesql.se> writes:
Since this will cause integer values to have different textual enum value
representations in 14 and 15+, do we want to skip two numbers by assigning the
next wait event the integer value of WAIT_EVENT_WAL_WRITE incremented by three?
Or enum integer reuse not something we guarantee against across major versions?We require a recompile across major versions. I don't see a reason why
this particular enum needs more stability than any other one.+1. That'd end up pushing us to be more conservative about defining new wait
events, which I think would be bad tradeoff.
Fair enough, makes sense.
--
Daniel Gustafsson https://vmware.com/
On Mon, Oct 25, 2021 at 01:18:26PM -0400, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
... But while I agree it's good to remove unused stuff in the
master, it doesn't seem like we really need to back-patch it.Yeah, exactly. I don't see any benefit that's commensurate with
even a small risk of breaking extensions --- and apparently, in
this case that's not a risk but a certainty.
+1.
--
MichaelOn Tue, Oct 26, 2021 at 6:50 AM Michael Paquier <michael@paquier.xyz> wrote:
On Mon, Oct 25, 2021 at 01:18:26PM -0400, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
... But while I agree it's good to remove unused stuff in the
master, it doesn't seem like we really need to back-patch it.Yeah, exactly. I don't see any benefit that's commensurate with
even a small risk of breaking extensions --- and apparently, in
this case that's not a risk but a certainty.+1.
I agree with the points raised here and will revert this for v14.
--
With Regards,
Amit Kapila.
On 26.10.21 04:20, Amit Kapila wrote:
I agree with the points raised here and will revert this for v14.
Thanks, Amit. I appreciate the revert.
Note that the removed events were almost at the end of WaitEventIO enum,
except for one last entry: WAIT_EVENT_WAL_WRITE.
Just as a data point: Our BDR extension indeed references the wait
events in question (or at least it used to do so up until that commit).
--
Markus Wanner
EDB: http://www.enterprisedb.com
On Tue, Oct 26, 2021 at 7:34 PM Markus Wanner
<markus.wanner@enterprisedb.com> wrote:
On 26.10.21 04:20, Amit Kapila wrote:
I agree with the points raised here and will revert this for v14.
Thanks, Amit. I appreciate the revert.
Note that the removed events were almost at the end of WaitEventIO enum,
except for one last entry: WAIT_EVENT_WAL_WRITE.Just as a data point: Our BDR extension indeed references the wait
events in question (or at least it used to do so up until that commit).
Thanks for the relevant information.
--
With Regards,
Amit Kapila.