Re: Missing update of all_hasnulls in BRIN opclasses
От | Tomas Vondra |
---|---|
Тема | Re: Missing update of all_hasnulls in BRIN opclasses |
Дата | |
Msg-id | 7332ad6c-a218-1b54-cfab-fe93ccbf15d6@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Missing update of all_hasnulls in BRIN opclasses (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Список | pgsql-hackers |
On 4/24/23 23:05, Tomas Vondra wrote: > > > On 4/24/23 17:46, Tom Lane wrote: >> Alvaro Herrera <alvherre@alvh.no-ip.org> writes: >>> On 2023-Apr-23, Tomas Vondra wrote: >>>> Both cases have a patch extending pageinspect to show the new flag, but >>>> obviously we should commit that only in master. In backbranches it's >>>> meant only to make testing easier. >> >>> In backbranches, I think it should be reasonably easy to add a >>> --1.7--1.7.1.sql file and set the default version to 1.7.1; that then >>> enables us to have the functionality (and the tests) in older branches >>> too. If you just add a --1.X.1--1.12.sql version to each branch that's >>> identical to that branch's current pageinspect version upgrade script, >>> that would let us have working upgrade paths for all branches. This is >>> a bit laborious but straightforward enough. >> >> "A bit laborious"? That seems enormously out of proportion to the >> benefit of putting this test case into back branches. It will have >> costs for end users too, not only us. As an example, it would >> unecessarily block some upgrade paths, if the upgraded-to installation >> is slightly older and lacks the necessary --1.X.1--1.12 script. >> > > Why would that block the upgrade? Presumably we'd add two upgrade > scripts in the master, to allow upgrade both from 1.X and 1.X.1. > D'oh! I just realized I misunderstood the issue. Yes, if the target version is missing the new script, that won't work. I'm not sure how likely that is - in my experience people refresh versions at the same time - but it's certainly an assumption we shouldn't do, I guess. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: