Обсуждение: Re: pgsql: Remove unused wait events.
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. -- Michael
Вложения
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.
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.