On Tue, Feb 2, 2016 at 7:22 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> Masahiko Sawada wrote:
>> I misunderstood. Sorry for noise.
>> I agree with adding conversion method as a pageConverter routine.
> \o/
>> 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?
> My vote is for #2 as well.  Maybe we just didn't have forks when this
> functionality was invented; maybe the author just didn't think hard
> enough about what would be the right interface to do it.


I'm planning to change as follows.
- pageCnvCtx struct has new function pointer convertVMFile().
  If the layout of other relation such as FSM, CLOG in the future, we
could add convertFSMFile() and convertCLOGFile().
- Create new library convertLayoutVM_add_frozenbit.c that has
convertVMFile() function which converts only visibilitymap.
  When rewriting of VM is required, convertLayoutVM_add_frozenbit.so
is dynamically loaded.
  convertLayout_X_to_Y converts other relation files.
  That is, converting VM and converting other relations are independently done.
- Current plugin mechanism puts conversion library (*.so) into
${bin}/plugins (i.g., new plugin directory is required), but I'm
thinking to puts it into ${libdir}.

Please give me feedbacks.


Masahiko Sawada

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to