Re: START_REPLICATION SLOT causing a crash in an assert build
От | Kyotaro Horiguchi |
---|---|
Тема | Re: START_REPLICATION SLOT causing a crash in an assert build |
Дата | |
Msg-id | 20221006.141046.2033876856853955342.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: START_REPLICATION SLOT causing a crash in an assert build (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: START_REPLICATION SLOT causing a crash in an assert build
Re: START_REPLICATION SLOT causing a crash in an assert build |
Список | pgsql-hackers |
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. 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. +1. FWIW, the atttached is an example of what it looks like if we avoid file format change. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Вложения
В списке pgsql-hackers по дате отправления: