From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, jcasanov(at)systemguards(dot)com(dot)ec, pgsql-hackers(at)postgresql(dot)org, John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
Subject: | Re: START_REPLICATION SLOT causing a crash in an assert build |
Date: | 2022-10-06 04:44:43 |
Message-ID: | Yz5dOxZTP0vFMlwA@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 05, 2022 at 11:24:57PM -0400, Jonathan S. Katz wrote:
> On 10/5/22 8:44 PM, Andres Freund wrote:
>> I have two ideas how to fix it. As a design constraint, I'd be interested in
>> the RMTs opinion on the following:
>> Is a cleaner fix that changes the stats format (i.e. existing stats will be
>> thrown away when upgrading) or one that doesn't change the stats format
>> preferrable?
>
> [My opinion, will let Michael/John chime in]
>
> Ideally we would keep the stats on upgrade -- I think that's the better user
> experience.
The release has not happened yet, so I would be fine to remain
flexible and bump again PGSTAT_FILE_FORMAT_ID so as we have the
cleanest approach in place for the release and the future. At the
end, we would throw automatically the data of a file that's marked
with a version that does not match with what we expect at load time,
so there's a limited impact on the user experience, except, well,
losing these stats, of course.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-10-06 04:52:46 | Re: installcheck-world concurrency issues |
Previous Message | David Rowley | 2022-10-06 03:32:25 | Re: shadow variables - pg15 edition |