Re: [BUGS] pg_upgrade issues
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 welcome any suggestions on how to do this. Your diagnosis is 100% on target, and very perceptive. Because we preserve pg_class.relfilenode, if the table has not been rebuilt, for example by CLUSTER, the old system the pg_class.oid and pg_class.relfilenode are the same, and hence pg_class.oid is preserved through pg_class.relfilenode during the migration. If they are different, e.g. they ran CLUSTER, pg_upgrade will be wrong because the oid has changed, and you will see the errors you are reporting. 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 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. Thank you for the explanation and the swift action. 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 the table that pulled the trigger (this is the case for some of our uses). Dmitry -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pg_upgrade issues
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 compressed and contains a lot of proprietary info. I would welcome any suggestions on how to do this. Your diagnosis is 100% on target, and very perceptive. Because we preserve pg_class.relfilenode, if the table has not been rebuilt, for example by CLUSTER, the old system the pg_class.oid and pg_class.relfilenode are the same, and hence pg_class.oid is preserved through pg_class.relfilenode during the migration. If they are different, e.g. they ran CLUSTER, pg_upgrade will be wrong because the oid has changed, and you will see the errors you are reporting. 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 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. Thank you for the explanation and the swift action. 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 the table that pulled the trigger (this is the case for some of our uses). OK, thanks. I was curious about your usage so I could determine how widespread usage of those reg* types is. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pg_upgrade issues
On Sat, Jul 24, 2010 at 11:37 PM, Bruce Momjian br...@momjian.us 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 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). This is a good change; however, there is still some potential for lossage here. What if the column were declared as type OID? Then it would be hard to tell whether migration was safe or not. Perhaps the right long-term solution is to try harder to preserve OIDs in more cases. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5571: global hash %_SHARED is not declared as global in the new version
The following bug has been logged online:
Bug reference: 5571
Logged by: mile
Email address: m...@avangardsolutions.com
PostgreSQL version: v9.0beta3
Operating system: Linux
Description:global hash %_SHARED is not declared as global in the
new version
Details:
We are using strict pragma that's why we are geting the following error:
ERROR: Global symbol %_SHARED requires explicit package name
However we should not get that error message because
the hash $_SHARED should be declared as global variable.
To reproduce this use the following function:
create or replace function perl_shared() returns void as $$
use strict;
elog(INFO, $_SHARED{'stuff'});
$_SHARED{'stuff'} = '1';
for my $k (keys %_SHARED)
{
elog(INFO, $k);
}
$$ language plperl;
CREATE LANGUAGE plperl;
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pg_upgrade issues
Robert Haas wrote: On Sat, Jul 24, 2010 at 11:37 PM, Bruce Momjian br...@momjian.us 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 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). This is a good change; however, there is still some potential for lossage here. What if the column were declared as type OID? Then it would be hard to tell whether migration was safe or not. Perhaps the right long-term solution is to try harder to preserve OIDs in more cases. You are right that an oid column cannot be tracked easily. It could refer to a user table with oids, or it might be a system row reference. I have considered preserving more oids, but that is going to increase the backend changes for pg_upgrade, and I am hesistant to do that until there is a claarer demand. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pg_upgrade issues
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 the table that pulled the trigger (this is the case for some of our uses). I've wanted to use regclass (and regproc too, for that matter) in some db designs, but I've refrained precisely because of the movability issues. Note that you can use TG_SCHEMANAME and TG_RELNAME in plpgsql triggers anyway. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5572: Error Trying to connec from Crystal Reports to Sever PostgreSQL
The following bug has been logged online: Bug reference: 5572 Logged by: Tizziano Perea Email address: tizzia...@gmail.com PostgreSQL version: 8.2.17 Operating system: CentOS 5.4 Description:Error Trying to connec from Crystal Reports to Sever PostgreSQL Details: Regards, Hi, i'm a System Engenieer from Clinica Vida - Cali, Colombia. I,ve been install Crystal Reports 11 in a WinXP machine, and when i tried to connect to PostgreSQL (CentOS 5.4) the following error appears: La conexion no es posible Detalles: 08001: Could not connect to the server Could not connect to remote socket: [Codigo de proveedor de Base de Datos: 101] I edited the pg.hba.conf and postgres.conf files, but the error persist. Thanks for your attention and your help Bye. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pg_upgrade issues
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 provides a convenient reference to the table that pulled the trigger (this is the case for some of our uses). I've wanted to use regclass (and regproc too, for that matter) in some db designs, but I've refrained precisely because of the movability issues. Were you worried about pg_upgrade movability issues, or just general movability issues? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] page corruption after moving tablespace
On Thu, 2010-07-22 at 23:50 -0700, Jeff Davis wrote: I was investigating some strange page corruption today in which the page was completely zeroed except for the LSN and TLI. I see that this was added to the 9.0 open items list, but it affects versions 8.3 and later. I should have indicated that in my initial report. Regards, Jeff Davis -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5571: global hash %_SHARED is not declared as global in the new version
On Mon, Jul 26, 2010 at 03:58, mile m...@avangardsolutions.com wrote:
To reproduce this use the following function:
create or replace function perl_shared() returns void as $$
use strict;
elog(INFO, $_SHARED{'stuff'});
$_SHARED{'stuff'} = '1';
for my $k (keys %_SHARED)
{
elog(INFO, $k);
}
$$ language plperl;
Great, Thanks! The below patch fixes it for me. Basically we
declared %_SHARED inside the PostgreSQL::InServer; package when it
needed to be declared in main::. For the curious 8.4 and down don't
have this issue as the use vars qw(%_SHARED) is in the PERL_BOOT
define, which gets run at the interp start-up time (basically its perl
-e PERL_BOOT).
*** a/src/pl/plperl/plc_perlboot.pl
--- b/src/pl/plperl/plc_perlboot.pl
***
*** 2,7
--- 2,8
# $PostgreSQL: pgsql/src/pl/plperl/plc_perlboot.pl,v 1.5 2010/02/16
21:39:52 adunstan Exp $
use 5.008001;
+ use vars qw(%_SHARED);
PostgreSQL::InServer::Util::bootstrap();
***
*** 9,15 package PostgreSQL::InServer;
use strict;
use warnings;
- use vars qw(%_SHARED);
sub plperl_warn {
(my $msg = shift) =~ s/\(eval \d+\) //g;
--- 10,15
*** a/src/pl/plperl/plc_perlboot.pl
--- b/src/pl/plperl/plc_perlboot.pl
***
*** 2,7
--- 2,8
# $PostgreSQL: pgsql/src/pl/plperl/plc_perlboot.pl,v 1.5 2010/02/16 21:39:52 adunstan Exp $
use 5.008001;
+ use vars qw(%_SHARED);
PostgreSQL::InServer::Util::bootstrap();
***
*** 9,15 package PostgreSQL::InServer;
use strict;
use warnings;
- use vars qw(%_SHARED);
sub plperl_warn {
(my $msg = shift) =~ s/\(eval \d+\) //g;
--- 10,15
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5572: Error Trying to connec from Crystal Reports to Sever PostgreSQL
Tizziano Perea tizzia...@gmail.com wrote: PostgreSQL version: 8.2.17 Operating system: CentOS 5.4 Description:Error Trying to connec from Crystal Reports to Sever I,ve been install Crystal Reports 11 in a WinXP machine, and when i tried to connect to PostgreSQL (CentOS 5.4) the following error appears: La conexion no es posible Detalles: 08001: Could not connect to the server Could not connect to remote socket: [Codigo de proveedor de Base de Datos: 101] I edited the pg.hba.conf and postgres.conf files, but the error persist. In the future it would be better to post such problems to the pgsql-general list, as this doesn't really sound like a bug in PostgreSQL; it sounds like you don't have everything configured correctly. Without seeing the changes you made to the .conf files and knowing how Crystal Reports is trying to connect, it's hard to guess what the problem may be. Please post the contents of the postgresql.conf and pg_hba.conf files with all comments removed. Also, please give any information you can about how Crystal Reports is trying to connect. Also something to consider: did you do the appropriate reload or restart to get PostgreSQL to notice the changes after you edited the .conf files? -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5571: global hash %_SHARED is not declared as global in the new version
Excerpts from Alex Hunsaker's message of lun jul 26 12:55:34 -0400 2010:
On Mon, Jul 26, 2010 at 03:58, mile m...@avangardsolutions.com wrote:
To reproduce this use the following function:
create or replace function perl_shared() returns void as $$
use strict;
elog(INFO, $_SHARED{'stuff'});
$_SHARED{'stuff'} = '1';
for my $k (keys %_SHARED)
{
elog(INFO, $k);
}
$$ language plperl;
Great, Thanks! The below patch fixes it for me.
Thanks, applied to 9.0 and HEAD. I added a simple regression test too.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
