On Wed, Dec 2, 2009 at 11:28 AM, Bruce Momjian wrote:
>> >
>> > set next_pg_class_oid = 12345;
>> > set next_pg_type_oid = 12346;
>> > set next_toast_table_oid = ...
>> > set next_toast_index_oid = ...
>> >
>> > and finally it could do CREATE TABLE. ?CREATE TYPE would only need
>> > next_pg_type_o
Merlin Moncure wrote:
> On Thu, Aug 6, 2009 at 9:28 AM, Tom Lane wrote:
> > The half-formed idea I had was a set of GUC variables:
> >
> > set next_pg_class_oid = 12345;
> > set next_pg_type_oid = 12346;
> > set next_toast_table_oid = ...
> > set next_toast_index_oid = ...
> >
> > and finally it c
Merlin Moncure writes:
> Is this idea still on the table for 8.5?
I've forgotten what the problem was?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
On Thu, Aug 6, 2009 at 9:28 AM, Tom Lane wrote:
> The half-formed idea I had was a set of GUC variables:
>
> set next_pg_class_oid = 12345;
> set next_pg_type_oid = 12346;
> set next_toast_table_oid = ...
> set next_toast_index_oid = ...
>
> and finally it could do CREATE TABLE. CREATE TYPE would
Tom Lane wrote:
> Bruce Momjian writes:
> > Peter Eisentraut wrote:
> >> That might be a bit excessive. As I understand it, arrays of built-in
> >> types
> >> (e.g., int[]) should work fine. I suspect the majority of uses of arrays
> >> will
> >> be with built-in types, so allowing that would
Bruce Momjian writes:
> Peter Eisentraut wrote:
>> That might be a bit excessive. As I understand it, arrays of built-in types
>> (e.g., int[]) should work fine. I suspect the majority of uses of arrays
>> will
>> be with built-in types, so allowing that would help a significant portion of
>> i
Greg Stark wrote:
> On Fri, Aug 7, 2009 at 1:56 AM, Bruce Momjian wrote:
> > ? ? ? ? ? ? ? ?o ?data type 'name' and is not the first column
> >
>
> What was that about?
We changed the alignment of the 'name' column:
/*
* v8_3_check_for_name_data_type_usage()
*
Dne 6.08.09 04:29, Tom Lane napsal(a):
Andrew Dunstan writes:
preventing a clash might be fairly difficult.
Yeah, I was just thinking about that. The easiest way to avoid
collisions would be to make pg_dump (in --binary-upgrade mode)
responsible for being sure that *every* new pg_type and p
On Fri, Aug 7, 2009 at 1:56 AM, Bruce Momjian wrote:
> o data type 'name' and is not the first column
>
What was that about?
--
greg
http://mit.edu/~gsstark/resume.pdf
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
On Aug 6, 2009, at 6:00 PM, Bruce Momjian wrote:
Yes, I have regression tests I run but they are not in CVS, partly
because they are tied to other scripts I have to manage server
settings.
Here are my scripts:
http://momjian.us/tmp/pg_migrator_test.tgz
One big problem is that pg_mi
Joshua D. Drake wrote:
> On Wed, 2009-08-05 at 22:57 -0400, Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> > >
> > Well, pg_migrator has gotten pretty far without supporting these
> > features, and I think I would have heard about it if someone had these
> > and migrated because vacuum analyze f
David E. Wheeler wrote:
> On Aug 6, 2009, at 7:28 AM, Tom Lane wrote:
>
> > That would cover the problem for OIDs needed during CREATE TABLE, but
> > what about types and enum values?
>
> I haven't been following this discussion very closely, but wanted to
> ask: is someone writing regression t
Peter Eisentraut wrote:
> On Thursday 06 August 2009 06:32:06 Bruce Momjian wrote:
> > I have applied the attached patch to pg_migrator to detect enum,
> > composites, and arrays. I tested it and the only error I got was with
> > the breakmigrator table that was supplied by Jeff, and once I remove
On Wed, 2009-08-05 at 22:57 -0400, Bruce Momjian wrote:
> Andrew Dunstan wrote:
> >
> Well, pg_migrator has gotten pretty far without supporting these
> features, and I think I would have heard about it if someone had these
> and migrated because vacuum analyze found it right away. I am afraid
>
On Thursday 06 August 2009 17:54:37 David E. Wheeler wrote:
> On Aug 6, 2009, at 7:28 AM, Tom Lane wrote:
> > That would cover the problem for OIDs needed during CREATE TABLE, but
> > what about types and enum values?
>
> I haven't been following this discussion very closely, but wanted to
> ask: i
On Aug 6, 2009, at 7:28 AM, Tom Lane wrote:
That would cover the problem for OIDs needed during CREATE TABLE, but
what about types and enum values?
I haven't been following this discussion very closely, but wanted to
ask: is someone writing regression tests for these cases that
pg_migrator
On Thu, Aug 6, 2009 at 4:32 AM, Dimitri Fontaine wrote:
> Tom Lane writes:
>
>> Andrew Dunstan writes:
>>> preventing a clash might be fairly difficult.
>>
>> Yeah, I was just thinking about that. The easiest way to avoid
>> collisions would be to make pg_dump (in --binary-upgrade mode)
>> respo
Andrew Dunstan writes:
> It's going to be fairly grotty whatever we do. I'm worried a bit that
> we'll be providing some footguns, but I guess we'll just need to hold
> our noses and do whatever it takes.
Yeah. One advantage of the GUC approach is we could make 'em SUSET.
I don't actually see
Tom Lane wrote:
Alvaro Herrera writes:
Dimitri Fontaine wrote:
It seems harder to come up with a general purpose syntax to support the
feature in case of toast tables, though.
There's already general purpose syntax for relation options which can be
used to get options th
Alvaro Herrera writes:
> Dimitri Fontaine wrote:
>> It seems harder to come up with a general purpose syntax to support the
>> feature in case of toast tables, though.
> There's already general purpose syntax for relation options which can be
> used to get options that do not ultimately end up in
Dimitri Fontaine wrote:
> Tom Lane writes:
> > We could stop doing that
> > once we have all the user tables in place --- I don't believe it's
> > necessary to preserve the OIDs of user indexes. But we need to
> > preserve toast table OIDs, and toast table index OIDs too if those
> > are created
On Thursday 06 August 2009 06:32:06 Bruce Momjian wrote:
> I have applied the attached patch to pg_migrator to detect enum,
> composites, and arrays. I tested it and the only error I got was with
> the breakmigrator table that was supplied by Jeff, and once I removed
> that table the migration wen
Tom Lane írta:
> At the moment it looks to me like pg_migrator has crashed and burned
> for 8.4, at least for general-purpose usage.
It means that you don't have the restraint that
you thought you have. So you can change the
RedHat/Fedora PostgreSQL 8.4 packages to use
the upstream default for int
Tom Lane writes:
> Andrew Dunstan writes:
>> preventing a clash might be fairly difficult.
>
> Yeah, I was just thinking about that. The easiest way to avoid
> collisions would be to make pg_dump (in --binary-upgrade mode)
> responsible for being sure that *every* new pg_type and pg_class row
>
Bruce Momjian wrote:
> Andrew Dunstan wrote:
> >
> >
> > Bruce Momjian wrote:
> > > Do we have no composite types in the regression tests, or do we not
> > > store any in the database? Same the enums.
> > >
> > >
> >
> > Looks like the enum regression tests at least drop all their tables :-(
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > Andrew Dunstan writes:
> >
> >> preventing a clash might be fairly difficult.
> >>
> >
> > Yeah, I was just thinking about that. The easiest way to avoid
> > collisions would be to make pg_dump (in --binary-upgrade mode)
> > responsible fo
Andrew Dunstan writes:
> Is there any danger that an oid used in, say, pg_enum in the old version
> will be used in the catalog bootstrap in the new version?
No. All initdb-assigned OIDs are less than 16K, and we never assign
such an OID post-initdb (not even when wrapping around). We might ge
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > Do we have no composite types in the regression tests, or do we not
> > store any in the database? Same the enums.
> >
> >
>
> Looks like the enum regression tests at least drop all their tables :-(
>
> > To allow pg_migrator to work, I w
Tom Lane wrote:
Andrew Dunstan writes:
preventing a clash might be fairly difficult.
Yeah, I was just thinking about that. The easiest way to avoid
collisions would be to make pg_dump (in --binary-upgrade mode)
responsible for being sure that *every* new pg_type and pg_class row
OI
Andrew Dunstan writes:
> preventing a clash might be fairly difficult.
Yeah, I was just thinking about that. The easiest way to avoid
collisions would be to make pg_dump (in --binary-upgrade mode)
responsible for being sure that *every* new pg_type and pg_class row
OID matches what it was in the
Bruce Momjian wrote:
Do we have no composite types in the regression tests, or do we not
store any in the database? Same the enums.
Looks like the enum regression tests at least drop all their tables :-(
To allow pg_migrator to work, I would need to reserve the oids in
pg_type, import
Bruce Momjian writes:
> To allow pg_migrator to work, I would need to reserve the oids in
> pg_type, import the dump, and renumber the pg_type entries (and
> everything pointing to them) to the proper pg_type.oid. The big problem
> there is that I don't have access at the SQL level to set or chan
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Hm ... has anyone tested pg_migrator using either composite types or
> >> arrays of user-defined types? Both of them have got user-defined-type
> >> OIDs in on-disk data, now that I think about it. For that matter, enums
> >> are
Tom Lane wrote:
> Bruce Momjian writes:
> > I received the following pg_migrator bug report today and was able to
> > reproduce the reported failure when using composite types:
>
> > test=> SELECT * FROM breakmigrator;
> > ERROR: cache lookup failed for type 27604
>
> Hm ... has anyone
Alvaro Herrera writes:
> Tom Lane wrote:
>> Hm ... has anyone tested pg_migrator using either composite types or
>> arrays of user-defined types? Both of them have got user-defined-type
>> OIDs in on-disk data, now that I think about it. For that matter, enums
>> are going to be a problem too.
Tom Lane wrote:
> Bruce Momjian writes:
> > I received the following pg_migrator bug report today and was able to
> > reproduce the reported failure when using composite types:
>
> > test=> SELECT * FROM breakmigrator;
> > ERROR: cache lookup failed for type 27604
>
> Hm ... has anyone
Bruce Momjian writes:
> I received the following pg_migrator bug report today and was able to
> reproduce the reported failure when using composite types:
> test=> SELECT * FROM breakmigrator;
> ERROR: cache lookup failed for type 27604
Hm ... has anyone tested pg_migrator using eit
Bruce Momjian wrote:
>
> I received the following pg_migrator bug report today and was able to
> reproduce the reported failure when using composite types:
>
> test=> SELECT * FROM breakmigrator;
> ERROR: cache lookup failed for type 27604
>
> test=> ANALYZE VERBOSE public.bre
I received the following pg_migrator bug report today and was able to
reproduce the reported failure when using composite types:
test=> SELECT * FROM breakmigrator;
ERROR: cache lookup failed for type 27604
test=> ANALYZE VERBOSE public.breakmigrator;
INFO: anal
39 matches
Mail list logo
