On Tue, Oct 26, 2021 at 7:34 PM Markus Wanner
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
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
On Tue, Oct 26, 2021 at 6:50 AM Michael Paquier wrote:
>
> On Mon, Oct 25, 2021 at 01:18:26PM -0400, Tom Lane wrote:
> > Robert Haas 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.
On Mon, Oct 25, 2021 at 01:18:26PM -0400, Tom Lane wrote:
> Robert Haas 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 ris
> On 25 Oct 2021, at 20:01, Andres Freund wrote:
>
> On 2021-10-25 13:39:44 -0400, Tom Lane wrote:
>> Daniel Gustafsson 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
>>
On 2021-10-25 13:39:44 -0400, Tom Lane wrote:
> Daniel Gustafsson 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_WR
Daniel Gustafsson 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 so
> On 25 Oct 2021, at 19:18, Tom Lane wrote:
>
> Robert Haas 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 break
Robert Haas 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
On Mon, Oct 25, 2021 at 12:38 PM Tom Lane 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
Robert Haas writes:
> On Wed, Oct 20, 2021 at 10:52 PM Amit Kapila 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
On Wed, Oct 20, 2021 at 10:52 PM Amit Kapila 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
12 matches
Mail list logo
