Robert Haas wrote:
> On Mon, Dec 28, 2009 at 10:48 AM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Sun, Dec 27, 2009 at 2:16 PM, Robert Haas wrote:
> >> > On Sun, Dec 27, 2009 at 9:53 AM, Bruce Momjian wrote:
> >> >> Bruce Momjian wrote:
> >> >>> There are several pg_migrator limitations
On Mon, Dec 28, 2009 at 10:48 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Sun, Dec 27, 2009 at 2:16 PM, Robert Haas wrote:
>> > On Sun, Dec 27, 2009 at 9:53 AM, Bruce Momjian wrote:
>> >> Bruce Momjian wrote:
>> >>> There are several pg_migrator limitations that appeared late in the 8.4
Robert Haas wrote:
> On Sun, Dec 27, 2009 at 2:16 PM, Robert Haas wrote:
> > On Sun, Dec 27, 2009 at 9:53 AM, Bruce Momjian wrote:
> >> Bruce Momjian wrote:
> >>> There are several pg_migrator limitations that appeared late in the 8.4
> >>> development cycle and were impossible to fix at that poi
On Sun, Dec 27, 2009 at 2:16 PM, Robert Haas wrote:
> On Sun, Dec 27, 2009 at 9:53 AM, Bruce Momjian wrote:
>> Bruce Momjian wrote:
>>> There are several pg_migrator limitations that appeared late in the 8.4
>>> development cycle and were impossible to fix at that point. I would
>>> like to fix
On Sun, Dec 27, 2009 at 5:15 PM, Bruce Momjian wrote:
>> Is that something we're comfortable adding in the final commitfest?
>
> Uh, no idea. It would be nice, of course.
Do we know if there's active development in progress on page CRCs? If
so, when can we expect to see a working patch?
With r
Greg Stark wrote:
> On Sun, Dec 27, 2009 at 8:13 PM, Bruce Momjian wrote:
> > Well, I think the checksums are going in the item pointers, so there
> > isn't any new storage space --- my guess is that the page version number
> > will control how the backend stores the checksum. ?Basically the backe
On Sun, Dec 27, 2009 at 8:13 PM, Bruce Momjian wrote:
> Well, I think the checksums are going in the item pointers, so there
> isn't any new storage space --- my guess is that the page version number
> will control how the backend stores the checksum. Basically the backend
> will need to read old
Greg Stark wrote:
> 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?
We
On Sun, Dec 27, 2009 at 9:53 AM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> There are several pg_migrator limitations that appeared late in the 8.4
>> development cycle and were impossible to fix at that point. I would
>> like to fix them for Postgres 8.5:
>>
>> o a user-defined comp
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" wrote:
>B
Bruce Momjian wrote:
> There are several pg_migrator limitations that appeared late in the 8.4
> development cycle and were impossible to fix at that point. I would
> like to fix them for Postgres 8.5:
>
> o a user-defined composite data type
> o a user-defined array data type
>
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> > > Tom Lane wrote:
> > > > Bruce Momjian 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-
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian 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
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > > Well, we might eventually allow addition of values to enums too; the
> > > fact that it's not implemented outside pg_migrator right now doesn't
> > > mean we won't ever think of a solution. In any case I'm not persuaded
> > > that a zero-element en
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > > Well, we might eventually allow addition of values to enums too; the
> > > fact that it's not implemented outside pg_migrator right now doesn't
> > > mean we won't ever think of a solution. In any case I'm not persuaded
> > > that a zero-element en
Bruce Momjian wrote:
> > Well, we might eventually allow addition of values to enums too; the
> > fact that it's not implemented outside pg_migrator right now doesn't
> > mean we won't ever think of a solution. In any case I'm not persuaded
> > that a zero-element enum is totally without value. T
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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" v
Tom Lane wrote:
> Bruce Momjian 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 stil
Bruce Momjian 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 t
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> The approach I originally suggested was to create the enum type with
> >> *no* members, and then add the values one at a time.
>
> > Well, I was hesitant to modify the grammar, unless we want the ability
> > to create enums with zer
Bruce Momjian wrote:
As far as the ability to add enum values using ALTER TYPE, it seems we
would need a pg_enum.enumnum column like we do for pg_attribute.attnum
and order on that rather than pg_enum.oid. (Binary upgrade would still
need to preserve oids.)
I don't that's necessarily a
Bruce Momjian writes:
> Tom Lane wrote:
>> The approach I originally suggested was to create the enum type with
>> *no* members, and then add the values one at a time.
> Well, I was hesitant to modify the grammar, unless we want the ability
> to create enums with zero values. Doing enum with onl
Bruce Momjian wrote:
> I have completed the attached patch which assigns oids for all pg_type
> rows when pg_dump --binary-upgrade is used. This allows user-defined
> arrays and composite types to be migrated cleanly. I tested a reload of
> the regression database with --binary-upgrade and all th
Tom Lane wrote:
> Bruce Momjian writes:
> > I thought of a cleaner approach. CREATE TYPE ENUM will create one enum
> > with the specified oid, and then a server-side function will call
> > EnumValuesCreate() be used to add each additional enum with a specified
> > oid --- no deleting necessary.
Bruce Momjian wrote:
I now think the easiest solution will be to have pg_dump create the enum
with a single dummy value, delete the pg_enum dummy row, and then call a
modified version of EnumValuesCreate() to insert row by row into
pg_enum, with specified oids.
I thought of a cleaner app
Bruce Momjian writes:
> I thought of a cleaner approach. CREATE TYPE ENUM will create one enum
> with the specified oid, and then a server-side function will call
> EnumValuesCreate() be used to add each additional enum with a specified
> oid --- no deleting necessary. I will start working on a
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > I looked at DefineEnum() and basically adding the ability to add enums
> > would put the new enum after the existing ones unless the OID counter
> > has wrapped around and is less than the oid counter at the time the enum
> > type was created, in whic
Bruce Momjian wrote:
> I looked at DefineEnum() and basically adding the ability to add enums
> would put the new enum after the existing ones unless the OID counter
> has wrapped around and is less than the oid counter at the time the enum
> type was created, in which case it will be listed as bef
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > I wasn't aware enum ordering is something we tried to maintain.
> > One issue is that we are not supporting the addition of enum values even
> > for people who don't care about the ordering of enums (which I bet might
> > be the majority.)
> >
Bruce Momjian wrote:
I wasn't aware enum ordering is something we tried to maintain.
One issue is that we are not supporting the addition of enum values even
for people who don't care about the ordering of enums (which I bet might
be the majority.)
The ordering of enums is defined and to b
Tom Lane wrote:
> Greg Stark writes:
> > On Wed, Dec 23, 2009 at 7:17 PM, Tom Lane wrote:
> >> The reason that isn't implemented is that it's *hard* --- in fact,
> >> it appears to be entirely impossible in the general case, unless you're
> >> willing to change existing values of the enum on-disk
Greg Stark writes:
> On Wed, Dec 23, 2009 at 8:09 PM, Tom Lane wrote:
>> If we're going to implement something whose ambitions only extend to
>> satisfying pg_migrator's needs, then it should be a specialized
>> pg_migrator function.
> Fwiw my feeling was the opposite here. It's better to offer
On Wed, Dec 23, 2009 at 8:09 PM, Tom Lane wrote:
> If we're going to implement something whose ambitions only extend to
> satisfying pg_migrator's needs, then it should be a specialized
> pg_migrator function.
Fwiw my feeling was the opposite here. It's better to offer even
limited SQL-level supp
Greg Stark writes:
> On Wed, Dec 23, 2009 at 7:17 PM, Tom Lane wrote:
>> The reason that isn't implemented is that it's *hard* --- in fact,
>> it appears to be entirely impossible in the general case, unless you're
>> willing to change existing values of the enum on-disk.
> Shouldn't adding new
On Wed, Dec 23, 2009 at 7:17 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> The remaining issue is pg_enum oids. Because it will be difficult to
>> pass an arbitrary number of oids into the backend, the idea was to
>> assign each enum value separately. If we implement this TODO item:
>
>>
Bruce Momjian writes:
> The remaining issue is pg_enum oids. Because it will be difficult to
> pass an arbitrary number of oids into the backend, the idea was to
> assign each enum value separately. If we implement this TODO item:
> Allow adding/renaming/removing enumerated values to an e
decibel writes:
> Is there some reason why OIDs were used for ENUM instead of a general
> sequence? Were we worried about people screwing with the sequence?
No, we were worried about being able to do enum_out without outside
information as to which enum type it is. If you don't mind doubling
th
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > ... The idea I had was to create a global structure:
> >
> > > struct pg_migrator_oids {
> > > Oid pg_type;
> > > Oid pg_type_array;
> > > ...
> > > }
> >
> > > This would initialize
On Dec 19, 2009, at 9:52 PM, Robert Haas wrote:
> On Sat, Dec 19, 2009 at 10:46 PM, Bruce Momjian wrote:
>> Tom Lane wrote:
Bruce Momjian wrote:
> Seems I need some help here.
>>>
>>> I'm willing to work on this --- it doesn't look particularly fun but
>>> we really need it.
>>
>> You d
Tom Lane wrote:
> Bruce Momjian writes:
> > Basically there isn't much extra work to go from 8.3 to 8.4 compared to
> > 8.3 to 8.5.
>
> That might be true today, but it will stop being true once we replace
> the oid/relfilenode management hac^Wcode with the proposed new approach.
>
> > The other
Bruce Momjian writes:
> Basically there isn't much extra work to go from 8.3 to 8.4 compared to
> 8.3 to 8.5.
That might be true today, but it will stop being true once we replace
the oid/relfilenode management hac^Wcode with the proposed new approach.
> The other problem with moving to /contrib
On Sun, 20 Dec 2009, Bruce Momjian wrote:
The other problem with moving to /contrib is that I can't put out
pg_migrator updates independently of the main community release, which
could be bad.
Why not?
Marc G. FournierHub.Org Hosting Solutions S.A.
scra...@hub.or
Tom Lane wrote:
> Robert Haas writes:
> > I agree that pulling pg_migrator into contrib seems pretty sensible.
> > What I want to make sure we're on the same page about is which
> > versions the 8.5 pg_migrator will allow you to upgrade from and to. I
> > think we should at least support 8.3 -> 8
Robert Haas writes:
> I agree that pulling pg_migrator into contrib seems pretty sensible.
> What I want to make sure we're on the same page about is which
> versions the 8.5 pg_migrator will allow you to upgrade from and to. I
> think we should at least support 8.3 -> 8.5 and 8.4 -> 8.5. If you
On Sun, Dec 20, 2009 at 2:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Dec 20, 2009 at 1:49 PM, Tom Lane wrote:
>>> There's a reason to clutter, eg, pg_dump with multiple version support.
>>> I don't see the argument for doing so with pg_migrator. Separate source
>>> code branches se
Robert Haas writes:
> On Sun, Dec 20, 2009 at 1:49 PM, Tom Lane wrote:
>> There's a reason to clutter, eg, pg_dump with multiple version support.
>> I don't see the argument for doing so with pg_migrator. Separate source
>> code branches seem like a much better idea.
> I guess we have to look a
On Sun, Dec 20, 2009 at 1:49 PM, Tom Lane wrote:
>> if (GET_MAJOR_VERSION(ctx.old.pg_version) <= 803 &&
>> GET_MAJOR_VERSION(ctx.new.pg_version) >= 804)
>
> Well, yeah, you can probably make it work if you're willing to carry
> enoguh version tests and alternate sets of logic in the so
Bruce Momjian writes:
> Tom Lane wrote:
>> I think you're just creating useless work for yourself by imagining that
>> pg_migrator is backend-version-independent. In fact, I was thinking
>> about proposing that we pull it in as a contrib module. Because so much
>> of what it does is tied to deta
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> What I had in mind was more like
> >>
> >> static Oid next_pg_class_oid = InvalidOid;
> >>
> >> void
> >> set_next_pg_class_oid(Oid oid)
> >> {
> >>next_pg_class_oid = oid;
> >> }
>
> > Does exporting a function buy us anythin
Bruce Momjian writes:
> Tom Lane wrote:
>> What I had in mind was more like
>>
>> static Oid next_pg_class_oid = InvalidOid;
>>
>> void
>> set_next_pg_class_oid(Oid oid)
>> {
>> next_pg_class_oid = oid;
>> }
> Does exporting a function buy us anything vs. exporting a variable?
Hmm, probab
Robert Haas wrote:
> On Sat, Dec 19, 2009 at 10:46 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> > Bruce Momjian wrote:
> >> >> Seems I need some help here.
> >>
> >> I'm willing to work on this --- it doesn't look particularly fun but
> >> we really need it.
> >
> > You don't know fun until y
On Sat, Dec 19, 2009 at 10:46 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> > Bruce Momjian wrote:
>> >> Seems I need some help here.
>>
>> I'm willing to work on this --- it doesn't look particularly fun but
>> we really need it.
>
> You don't know fun until you have tried to stack hack upon hack
Tom Lane wrote:
> > Bruce Momjian wrote:
> >> Seems I need some help here.
>
> I'm willing to work on this --- it doesn't look particularly fun but
> we really need it.
You don't know fun until you have tried to stack hack upon hack and
still create a reliable migration system. :-(
--
Bruce
Tom Lane wrote:
> Bruce Momjian writes:
> > ... The idea I had was to create a global structure:
>
> > struct pg_migrator_oids {
> > Oid pg_type;
> > Oid pg_type_array;
> > ...
> > }
>
> > This would initialize to zero as a global structure, an
Joe Conway writes:
> I like this approach overall, but wonder if it would be better to do:
> select pg_migrator_set_next_oid('table', 123456);
> select pg_migrator_set_next_oid('type', 12347);
> select pg_migrator_set_next_oid('toast_table', 123458);
> etc. Later we could easily
Bruce Momjian writes:
> ... The idea I had was to create a global structure:
> struct pg_migrator_oids {
> Oid pg_type;
> Oid pg_type_array;
> ...
> }
> This would initialize to zero as a global structure, and only
> pg_migrator serve
On 12/18/2009 04:09 PM, Tom Lane wrote:
> At the moment it appears that we need the following hacks:
>
> * ability to control the OIDs assigned to user tables and types.
> Because a table also has a rowtype, this means at least two separate
> state variables. And we already knew we had to control
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> select pg_migrator_set_next_table_oid(123456);
> >> select pg_migrator_set_next_type_oid(12347);
> >> select pg_migrator_set_next_toast_table_oid(123458);
> >>
> >> CREATE TABLE ...
>
> > Do we also need a knob for the table type'
Tom Lane wrote:
> The more I think about it the less I want such warts placed in the
> regular SQL syntax for creation commands. As soon as we add a wart like
> that we'll be stuck with supporting it forever. Whatever we do here
> should be off in a little corner that only pg_migrator can get at.
Bruce Momjian wrote:
> > I think the OIDs for user-defined arrays stored in table data are
> > element types, not the array type which is what you're pointing at with
> > the line you quote:
> >
> > > > > array_oid = GetNewOid(pg_type);
> >
> > IMBFOS.
>
> Oh, yea, sorry, I was just showin
Alvaro Herrera writes:
> Tom Lane wrote:
>> select pg_migrator_set_next_table_oid(123456);
>> select pg_migrator_set_next_type_oid(12347);
>> select pg_migrator_set_next_toast_table_oid(123458);
>>
>> CREATE TABLE ...
> Do we also need a knob for the table type's array type?
Well, we wouldn't c
Tom Lane wrote:
At the moment it appears that we need the following hacks:
* ability to control the OIDs assigned to user tables and types.
Because a table also has a rowtype, this means at least two separate
state variables. And we already knew we had to control the OIDs
assigned to toast ta
Tom Lane wrote:
> * ability to control the OIDs assigned to user tables and types.
> Because a table also has a rowtype, this means at least two separate
> state variables. And we already knew we had to control the OIDs
> assigned to toast tables. I'm imagining dump output like
>
> select
> Bruce Momjian wrote:
>> Seems I need some help here.
I'm willing to work on this --- it doesn't look particularly fun but
we really need it.
Andrew Dunstan writes:
> I thought there was a suggestion that we would be able to specify the
> oids in the SQL that creates the types, along the lines
On Fri, Dec 18, 2009 at 6:44 PM, Andrew Dunstan wrote:
> I thought there was a suggestion that we would be able to specify the oids
> in the SQL that creates the types, along the lines of:
>
> create type foo as enum ( ...) with oids ( ... );
>
> Is that a non-starter? I imagine it would need to
Bruce Momjian wrote:
There are several pg_migrator limitations that appeared late in the 8.4
development cycle and were impossible to fix at that point. I would
like to fix them for Postgres 8.5:
o a user-defined composite data type
o a user-defined array data type
o
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > > > Alvaro Herrera wrote:
>
> > > > > To be more precise, the pg_enum.oid needs to be set for ENUM types;
> > > > > there's no need for setting the pg_type.oid (for ENUM types). I don't
> > > > >
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > Alvaro Herrera wrote:
> > > > To be more precise, the pg_enum.oid needs to be set for ENUM types;
> > > > there's no need for setting the pg_type.oid (for ENUM types). I don't
> > > > know about composites but I think the
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > > > There are several pg_migrator limitations that appeared late in the 8.4
> > > > development cycle and were impossible to fix at that point. I would
> > > > like to fix them for Postgres 8.5:
>
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > There are several pg_migrator limitations that appeared late in the 8.4
> > > development cycle and were impossible to fix at that point. I would
> > > like to fix them for Postgres 8.5:
> > >
> > > o a user-defi
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > There are several pg_migrator limitations that appeared late in the 8.4
> > development cycle and were impossible to fix at that point. I would
> > like to fix them for Postgres 8.5:
> >
> > o a user-defined composite data type
> >
Bruce Momjian wrote:
> There are several pg_migrator limitations that appeared late in the 8.4
> development cycle and were impossible to fix at that point. I would
> like to fix them for Postgres 8.5:
>
> o a user-defined composite data type
> o a user-defined array data type
>
There are several pg_migrator limitations that appeared late in the 8.4
development cycle and were impossible to fix at that point. I would
like to fix them for Postgres 8.5:
o a user-defined composite data type
o a user-defined array data type
o a user-defined enum dat
73 matches
Mail list logo
