On 2020-Jul-07, Peter Geoghegan wrote: > On Tue, Jul 7, 2020 at 1:18 PM Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: > > Yeah, backporting GUCs is not a big deal. Sure, the GUC won't appear in > > postgresql.conf files generated by initdb prior to the release that > > introduces it. But users that need it can just edit their .confs and > > add the appropriate line, or just do ALTER SYSTEM after the minor > > upgrade. > > I don't buy that argument myself. At a minimum, if we do it then we > ought to feel bad about it. It should be rare.
Judging history, it's pretty clear that it *is* rare. I'm not suggesting we do it now. I'm just contesting the assertion that it's impossible. > The fact that you can have a replica on an earlier point release > enforces the idea that it ought to be broadly compatible. A replica without hash_mem is not going to fail if the primary is upgraded to a version with hash_mem, so I'm not sure this argument means anything in this case. In any case, when we add WAL message types in minor releases, users are suggested to upgrade the replicas first; if they fail to do so, the replicas shut down when they reach a WAL point where the primary emitted the new message. Generally speaking, we *don't* promise that running a replica with an older minor always works, though obviously it does work most of the time. > Technically > users are not guaranteed that this will work, just like there are no > guarantees about WAL compatibility across point releases. We > nevertheless tacitly provide a "soft" guarantee that we won't break > WAL -- and that we won't add entirely new GUCs in a point release. Agreed, we do provide those guarantees. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
