Horton

Thread

Commits

  1. Revert "Remove unused wait events."

  2. Remove unused wait events.

  3. Add support for streaming to built-in logical replication.

  1. pgsql: Remove unused wait events.

    Amit Kapila <akapila@postgresql.org> — 2021-10-21T02:52:04Z

    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: https://postgr.es/m/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(-)

  2. Re: pgsql: Remove unused wait events.

    Robert Haas <robertmhaas@gmail.com> — 2021-10-25T16:17:53Z

    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

  3. Re: pgsql: Remove unused wait events.

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-10-25T16:38:38Z

    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

  4. Re: pgsql: Remove unused wait events.

    Robert Haas <robertmhaas@gmail.com> — 2021-10-25T17:10:25Z

    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

  5. Re: pgsql: Remove unused wait events.

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-10-25T17:18:26Z

    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

  6. Re: pgsql: Remove unused wait events.

    Daniel Gustafsson <daniel@yesql.se> — 2021-10-25T17:34:37Z

    > 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/

  7. Re: pgsql: Remove unused wait events.

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-10-25T17:39:44Z

    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

  8. Re: pgsql: Remove unused wait events.

    Andres Freund <andres@anarazel.de> — 2021-10-25T18:01:22Z

    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.

  9. Re: pgsql: Remove unused wait events.

    Daniel Gustafsson <daniel@yesql.se> — 2021-10-25T18:03:54Z

    > 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/

  10. Re: pgsql: Remove unused wait events.

    Michael Paquier <michael@paquier.xyz> — 2021-10-26T01:19:53Z

    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.
--
Michael

  11. Re: pgsql: Remove unused wait events.

    Amit Kapila <amit.kapila16@gmail.com> — 2021-10-26T02:20:06Z

    On 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.

  12. Re: pgsql: Remove unused wait events.

    Markus Wanner <markus.wanner@enterprisedb.com> — 2021-10-26T14:02:22Z

    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

  13. Re: pgsql: Remove unused wait events.

    Amit Kapila <amit.kapila16@gmail.com> — 2021-10-27T02:00:20Z

    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.