> Alvaro Herrera writes:
> > Excerpts from depstein's message of lun jul 26 08:05:24 -0400 2010:
> >> I just want to note that one reason regclass may be used in user
> tables (as opposed to, say, regtype) is that in PL/pgSQL trigger
> procedures there is a special variable TG_RELID, which provide
Alvaro Herrera writes:
> Excerpts from depstein's message of lun jul 26 08:05:24 -0400 2010:
>> I just want to note that one reason regclass may be used in user tables (as
>> opposed to, say, regtype) is that in PL/pgSQL trigger procedures there is a
>> special variable TG_RELID, which provides
Alvaro Herrera wrote:
> Excerpts from depstein's message of lun jul 26 08:05:24 -0400 2010:
>
> > I just want to note that one reason regclass may be used in user tables (as
> > opposed to, say, regtype) is that in PL/pgSQL trigger procedures there is a
> > special variable TG_RELID, which provi
Excerpts from depstein's message of lun jul 26 08:05:24 -0400 2010:
> I just want to note that one reason regclass may be used in user tables (as
> opposed to, say, regtype) is that in PL/pgSQL trigger procedures there is a
> special variable TG_RELID, which provides a convenient reference to th
Robert Haas wrote:
> On Sat, Jul 24, 2010 at 11:37 PM, Bruce Momjian wrote:
> >> I am inclined to prevent pg_upgrade from migrating any database that
> >> uses any of these reg* data types, and document this restriction. ?I
> >> probably could allow regtype because that pg_type is preserved.
> >
>
On Sat, Jul 24, 2010 at 11:37 PM, Bruce Momjian wrote:
>> I am inclined to prevent pg_upgrade from migrating any database that
>> uses any of these reg* data types, and document this restriction. I
>> probably could allow regtype because that pg_type is preserved.
>
> I have applied the attached
depst...@alliedtesting.com wrote:
> > Bruce Momjian wrote:
> > > depst...@alliedtesting.com wrote:
> > > > I am trying to obtain a binary dump of a small test database where
> > > > this issue could be reproduced, but so far, no luck. At present,
> > the
> > > > least such database is 1.5 GB compre
> Bruce Momjian wrote:
> > depst...@alliedtesting.com wrote:
> > > I am trying to obtain a binary dump of a small test database where
> > > this issue could be reproduced, but so far, no luck. At present,
> the
> > > least such database is 1.5 GB compressed and contains a lot of
> > > proprietary i
Bruce Momjian wrote:
> I have applied the attached patch to CVS HEAD and 9.0 that prevent
> migration when any reg* data type is used in a user table (except
> regtype because pg_type.oid is preserved).
>
> I documented this restriction. Thanks again for the report.
Attached is a secondary patch
Bruce Momjian wrote:
> depst...@alliedtesting.com wrote:
> > I am trying to obtain a binary dump of a small test database where this
> > issue could be reproduced, but so far, no luck. At present, the least
> > such database is 1.5 GB compressed and contains a lot of proprietary
> > info. I would w
depst...@alliedtesting.com wrote:
> I have encountered another problem with pg_upgrade, while migrating
> from 8.4 to 9.0 (beta2, as well as beta3) on Windows XP Pro.
Wow, your testing of pg_upgrade has been excellent! I hope you can
continue and test other areas of our system too. I am actually
I have encountered another problem with pg_upgrade, while migrating from 8.4 to
9.0 (beta2, as well as beta3) on Windows XP Pro.
I have a table with a regclass column, which references other tables in the
same database:
CREATE TABLE common_inst.reg_asset
(
asset_id integer NOT NULL,
table_n
depst...@alliedtesting.com wrote:
> Encountered another problem with pg_upgrade on Windows XP Pro:
>
> I was trying to migrate from 8.4 to 9.0beta2 without linking, and
> apparently there was not enough space on the hard drive. However,
> pg_upgrade didn't report any problems, and it looked for al
Encountered another problem with pg_upgrade on Windows XP Pro:
I was trying to migrate from 8.4 to 9.0beta2 without linking, and apparently
there was not enough space on the hard drive. However, pg_upgrade didn't report
any problems, and it looked for all the world as if everything went well. I
Hiroshi Saito wrote:
> Hi.
>
> Ooops, I can't follow your quick thread
> sorry, It will be a weekend if allowed.
I have replied and I think I have it fixed.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is g
Hi.
Ooops, I can't follow your quick thread
sorry, It will be a weekend if allowed.
Regards,
Hiroshi Saito
- Original Message -
From: "Bruce Momjian"
depst...@alliedtesting.com wrote:
BB> PostgreSQL 9.0 beta 2
Windows XP Professional SP2
While migrating the database fro
depst...@alliedtesting.com wrote:
BB> PostgreSQL 9.0 beta 2
> Windows XP Professional SP2
>
> While migrating the database from 8.4 to 9.0 using pg_upgrade (now part of
> the Postgres project), the following issues came up:
>
> 1. When using the --logfile option, pg_upgrade quits with an err
Another issue:
4. The --link option doesn't seem to work on Windows: pg_upgrade still copies
data from the old cluster to the new. There doesn't appear to be a way to
upgrade a database on Windows without copying the entire uncompressed database,
which can be a problem where disk space is limit
PostgreSQL 9.0 beta 2
Windows XP Professional SP2
While migrating the database from 8.4 to 9.0 using pg_upgrade (now part of the
Postgres project), the following issues came up:
1. When using the --logfile option, pg_upgrade quits with an error like this:
The process cannot access the file beca
19 matches
Mail list logo
