Thread: Re: pgsql: Remove unused wait events.

Re: pgsql: Remove unused wait events.

From
Robert Haas
Date:
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



Re: pgsql: Remove unused wait events.

From
Tom Lane
Date:
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



Re: pgsql: Remove unused wait events.

From
Robert Haas
Date:
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



Re: pgsql: Remove unused wait events.

From
Tom Lane
Date:
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



Re: pgsql: Remove unused wait events.

From
Daniel Gustafsson
Date:
> 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/




Re: pgsql: Remove unused wait events.

From
Tom Lane
Date:
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



Re: pgsql: Remove unused wait events.

From
Andres Freund
Date:
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.



Re: pgsql: Remove unused wait events.

From
Daniel Gustafsson
Date:
> 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/




Re: pgsql: Remove unused wait events.

From
Michael Paquier
Date:
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

Attachment

Re: pgsql: Remove unused wait events.

From
Amit Kapila
Date:
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.



Re: pgsql: Remove unused wait events.

From
Markus Wanner
Date:
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



Re: pgsql: Remove unused wait events.

From
Amit Kapila
Date:
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.