Re: Impact of checkpointer during pg_upgrade
От | Amit Kapila |
---|---|
Тема | Re: Impact of checkpointer during pg_upgrade |
Дата | |
Msg-id | CAA4eK1KcQ5cVq9T1-_ZrXjHR=XRZNgWZgaNbHfZLN-Sb-WZXgQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Impact of checkpointer during pg_upgrade (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Impact of checkpointer during pg_upgrade
|
Список | pgsql-hackers |
On Fri, Sep 8, 2023 at 5:37 AM Michael Paquier <michael@paquier.xyz> wrote: > > On Thu, Sep 07, 2023 at 03:33:52PM +0530, Amit Kapila wrote: > > I think if we just make max_slot_wal_keep_size to -1 that should be > > sufficient to not let any slots get invalidated during upgrade. Do you > > have anything else in mind? > > Forcing wal_keep_size while on it may be a good thing. > I had thought about it but couldn't come up with a reason to force wal_keep_size for this purpose. > > If we do (b) either via GUCs or IsBinaryUpgrade check we don't need to > > do any of (a), (b), or (d). I feel that would be a minimal and > > sufficient fix to prevent any side impact of checkpointer on slots > > during an upgrade. > > I could get into the addition of a post-upgrade check to make sure > that nothing got invalidated while the upgrade was running, FWIW. > This validation tries to ensure that we don't have any bugs/issues in our patch. It may be a candidate for assert but I feel even if we encounter any bug it is better to fix the bug. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: