Re: START_REPLICATION SLOT causing a crash in an assert build
От | Jonathan S. Katz |
---|---|
Тема | Re: START_REPLICATION SLOT causing a crash in an assert build |
Дата | |
Msg-id | 3067a888-00b0-b649-eff6-36efa0484847@postgresql.org обсуждение исходный текст |
Ответ на | Re: START_REPLICATION SLOT causing a crash in an assert build (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | pgsql-hackers |
On 10/6/22 1:10 AM, Kyotaro Horiguchi wrote: > At Thu, 6 Oct 2022 13:44:43 +0900, Michael Paquier <michael@paquier.xyz> wrote in >> 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. Yes, I agree with this. > 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. I'm fine with this. > +1. FWIW, the atttached is an example of what it looks like if we > avoid file format change. Thanks for the quick turnaround. I'll let others chime in on the review. Thanks, Jonathan
Вложения
В списке pgsql-hackers по дате отправления: