From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Subject: | Re: Removing pg_migrator limitations |
Date: | 2009-12-27 16:11:07 |
Message-ID: | e048f22a-4fa2-4ba0-9158-9bcc082a7879@email.android.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I'm kind of curious about the heap page conversion plan. I think we have a plan for how to do page checksums now if someone submits it now will we have time to do the page wok to handle page conversions? Or if not, are we better off waiting till 8.6 to get checksums?
"Bruce Momjian" <bruce(at)momjian(dot)us> wrote:
>Bruce Momjian wrote:
>> Bruce Momjian wrote:
>> > Bruce Momjian wrote:
>> > > Tom Lane wrote:
>> > > > Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> > > > > Tom Lane wrote:
>> > > > >> The reason I don't want to do it that way is that then you need two
>> > > > >> ugly kluges in the backend, not just one. With the zero-and-add-one
>> > > > >> approach there is no need to have a "next enum oid" variable at all.
>> > > >
>> > > > > Uh, I still need that variable because that is how we are going to set
>> > > > > the oid in EnumValuesCreate(), unless we want to add dummy oid-value
>> > > > > arguments to that function for use only by the binary upgrade
>> > > > > server-side function.
>> > > >
>> > > > Please go back and re-read what I suggested: you need a function along
>> > > > the lines of
>> > > > add_enum_member(enum-type, 'value name', value-oid)
>> > > > and then there's no need for any saved state. So what if it has a
>> > > > different signature from the other pg_migrator special functions?
>> > > > It's not doing the same thing.
>> > >
>> > > OK, right, I can get rid of the enum function that just sets the next
>> > > oid value if I do all the enum value creation via function calls. I
>> > > will work in that direction then.
>> >
>> > There is only one call to EnumValuesCreate() so maybe adding a
>> > binary-upgrade-only parameter to the function will be the cleanest
>> > approach.
>>
>> Here is a patch to allow EnumValuesCreate() to create labels with
>> specified oids, with pg_dump support. This is done cleanly now that we
>> allow zero-label enums.
>
>Applied. I also bumped the catalog version so pg_migrator can detect
>the new backend API by looking at pg_control.
>
>--
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
--
Sent from my Android phone with K-9. Please excuse my brevity.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-12-27 17:59:47 | Re: parse_oper cache |
Previous Message | Bruce Momjian | 2009-12-27 14:53:52 | Re: Removing pg_migrator limitations |