Re: Freeze avoidance of very large table.
От | Masahiko Sawada |
---|---|
Тема | Re: Freeze avoidance of very large table. |
Дата | |
Msg-id | CAD21AoDQJ455FdkVJbskxkUNsemQzS3bq-jw+Ahw5UJKma4NCw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Freeze avoidance of very large table. (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: Freeze avoidance of very large table.
|
Список | pgsql-hackers |
On Tue, Feb 2, 2016 at 10:15 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: > On 2/1/16 4:59 PM, Alvaro Herrera wrote: >> >> Masahiko Sawada wrote: >> >>> Attached updated version patch. >>> Please review it. >> >> >> In pg_upgrade, the "page convert" functionality is there to abstract >> rewrites of pages being copied; your patch is circumventing it and >> AFAICS it makes the interface more complicated for no good reason. I >> think the real way to do that is to write your rewriteVisibilityMap as a >> pageConverter routine. That should reduce some duplication there. > This means that user always have to set pageConverter plug-in when upgrading? I was thinking that this conversion is required for all user who wants to upgrade to 9.6, so we should support it in core, not as a plug-in. > > IIRC this is about the third problem that's been found with pg_upgrade in > this patch. That concerns me given the potential for disaster if freeze bits > are set incorrectly. Yeah, I tend to have diagnostic tool for visibilitymap, and to exactly compare VM between old one and new one after upgrading postgres server. I've implemented a such tool that is in my github repository[1]. I'm thinking to add this tool into core(e.g., pg_upgrade directory, not contrib module) as testing function. [1] https://github.com/MasahikoSawada/pg_visibilitymap Regards, -- Masahiko Sawada
В списке pgsql-hackers по дате отправления: