[PATCH] Make spelling consistent in waiteventset.c

Summary

This is a trivial cosmetic cleanup patch submitted against src/backend/storage/ipc/waiteventset.c. It is not an architecturally significant thread — it contains a single message with no replies in the provided corpus — but it is worth recording because it touches a central piece of PostgreSQL infrastructure (the WaitEventSet abstraction) and illustrates the project's norms around spelling/style consistency.

Technical Context

What waiteventset.c does

WaitEventSet is PostgreSQL's portable abstraction over OS-level readiness notification mechanisms. It was split out of latch.c into its own translation unit (waiteventset.c) relatively recently. The file contains four mutually-exclusive backend implementations selected at build time:

• epoll (Linux) — WaitEventSetWaitBlock calls epoll_wait() and translates EPOLLIN/EPOLLOUT into WL_SOCKET_READABLE/WL_SOCKET_WRITEABLE.
• kqueue (BSD/macOS) — uses kevent() with EVFILT_READ/EVFILT_WRITE.
• poll (generic POSIX fallback) — uses poll(2) with POLLIN/POLLOUT.
• Windows — uses WaitForMultipleObjects + WSAEventSelect.

Each of these backends has a structurally parallel block of code that decodes OS-level readiness flags into PostgreSQL's WL_* bitmask. Historically these four blocks were written/edited by different contributors at different times, which is exactly the kind of situation that produces drift in comment wording.

The specific inconsistency

Two of the four backends spelled the readiness direction "writable" in their comments and two spelled it "writeable". Both are valid English, but in a codebase the size of PostgreSQL such drift degrades greppability and makes it marginally harder for reviewers to confirm that the four backends are doing the analogous thing.

The patch normalizes all four occurrences to "writable", matching:

• the predominant spelling elsewhere in waiteventset.c,
• the spelling used in select(2)/poll(2) man page tradition ("ready for writing") and much of the surrounding PostgreSQL documentation.

Why the macro name is left alone

The submitter explicitly notes that WL_SOCKET_WRITEABLE is not being renamed. This is the correct call and reflects an understanding of PostgreSQL's API stability conventions:

• WL_SOCKET_WRITEABLE is part of the public latch/wait-event API exposed through storage/latch.h (now storage/waiteventset.h).
• It is used by extensions (e.g., logical replication output plugins, custom background workers, FDWs that do async I/O via WaitLatchOrSocket) and by third-party code out of tree.
• Renaming it would be an ABI/source-compatibility break for zero functional benefit. The cost/benefit of such a rename has been discussed on -hackers before for similar identifiers and the project has consistently declined to churn public symbols purely for spelling.

So the patch deliberately accepts a small residual inconsistency (macro uses "WRITEABLE", comments use "writable") as the lesser evil.

Design Decisions and Tradeoffs

1. Direction of normalization ("writable" vs "writeable"). Choosing "writable" aligns comments with the majority of existing prose in the file and in PostgreSQL docs, even though it diverges from the macro spelling. The alternative — standardizing comments on "writeable" to match the macro — would have required changing more sites and would have pushed the tree further from standard American technical English.

2. Scope discipline. The patch is strictly comment-only. It does not:

   • touch the WL_SOCKET_WRITEABLE macro,
   • reflow or re-indent code,
   • attempt to deduplicate the four parallel decode blocks (a real refactor that has been floated occasionally but is out of scope here).

   Keeping the diff minimal maximizes the chance of a committer picking it up as a drive-by cleanup.

3. No behavioral change, no tests needed. Because only comments are touched, there is no need for regression test updates, no catversion bump, and no backpatch consideration — this is master-only trivia.

Likely Committer Reception

Patches of this shape (comment/spelling normalization in hot, well-known files) are routinely committed by whichever committer is in a housekeeping mood — often Michael Paquier, Tom Lane, or Álvaro Herrera for this kind of janitorial work. Expected review comments, if any, would be limited to:

• confirming the chosen spelling ("writable") is indeed the house style, and
• verifying that no other comments in the same file were missed.

There is essentially no technical controversy here. The only "tradeoff" worth recording is the asymmetry with the public macro name, and the submitter preemptively addressed it in the cover message.

Broader Significance

While the patch itself is negligible, it is a useful data point about two PostgreSQL engineering norms:

• Public identifiers are sacrosanct even when misspelled/awkward. The project prefers internal inconsistency over breaking extension authors.
• Structurally parallel code paths (the four WES backends) are expected to be textually parallel as well, down to comment wording, because that parallelism is what lets reviewers verify correctness by visual diffing across backends.