On Wed, Mar 25, 2026 at 07:03:01AM +0100, Laurenz Albe wrote:
> On Tue, 2026-03-24 at 14:11 -0400, Bruce Momjian wrote:
> > On Tue, Mar 24, 2026 at 05:53:27PM +0100, Laurenz Albe wrote:
> > > Bruce, you are confusing me. Your first sentence suggests that you
> > > (erroneously) thought that upgrading statistics only works when upgrading
> >
> > Right.
> >
> > > *from* v18 or better. But your last sentence suggests that you'd rather
> > > not add anything to the documentation that could dispel that misconception.
> >
> > So, we don't normally document cases where a limitation does not exist.
> > I think the logical place to document this is in the PG 18 release
> > notes. I am still confused why people, like myself, got this wrong.
> > What is the source of the confusion? Just unclear release notes?
>
> I understand now, thanks. I agree with you in principle, but I wouldn't
> see that as a hard rule that should stand in the way of clarity.
>
> Let me quote a precedent from https://www.postgresql.org/docs/current/upgrading.html
>
> Minor releases never change the internal storage format and are always
> compatible with earlier and later minor releases of the same major
> version number. For example, version 10.1 is compatible with version 10.0
> and version 10.6.
>
> To me, that clarifies that there is no limitation to performing minor
> updates with a simple restart. I think that is useful information.
Right.
> Perhaps you'd feel better if we phrase it as a limitation:
>
> Transferring optimizer statistics only work when upgrading to PostgreSQL
> version v18 or later, but there is no such limitation to the version of
> the old cluster.
>
> I like my original suggestion better, though.
Uh, we added the feature in PG 18, so why would we say it only works in
PG 18 --- that is kind of obvious. I am still asking, why did people,
like me, think it only worked for _old_ PG 18 servers. If we find where
that was communicated, we can clarify it _there_.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
