Re: Freeze avoidance of very large table.
От | Masahiko Sawada |
---|---|
Тема | Re: Freeze avoidance of very large table. |
Дата | |
Msg-id | CAD21AoDB-J1b=fs63HFu7hMJ7zoH-B5W7RgqT=7Eds7uObqz0A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Freeze avoidance of very large table. (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Freeze avoidance of very large table.
|
Список | pgsql-hackers |
On Tue, Feb 2, 2016 at 11:42 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: > 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. I misunderstood. Sorry for noise. I agree with adding conversion method as a pageConverter routine. This patch doesn't change page layout actually, but pageConverter routine checks only the page layout. And we have to plugin named convertLayout_X_to_Y. I think we have two options. 1. Change page layout(PG_PAGE_LAYOUT_VERSION) to 5. pg_upgrade detects it and then converts only VM files. 2. Change pg_upgrade plugin mechanism so that it can handle other name conversion plugins (e.g., convertLayout_vm_to_vfm) I think #2 is better. Thought? Regards, -- Masahiko Sawada
В списке pgsql-hackers по дате отправления: