Re: [BUGS] Upgrading from < 8.1 with users and groups with same name
Hi Bruce! Bruce Momjian [2005-12-29 20:06 -0500]: > I think we decided that the number of users who have this problem and > would be using upgraded pg_dumpall to upgrade to 8.1 is too small. (If > we had realized this problem pre-8.1, it would have been great to have > fixed it.) In your upgrade script, you _know_ they are going to use > your code for the upgrade so it is much more useful for you to check it. Fine for me; of course I cannot force Debian users to use pg_upgradecluster (the script that contains all the hairy details and checks), there are people who do it the manual way. I just reported it here since other distributions have the same problem, so knowing the official upstream approach is always helpful. :) Thank you, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Upgrading from < 8.1 with users and groups with same name
Hi! Tom Lane [2005-12-29 22:20 -0500]: > Martin Pitt <[EMAIL PROTECTED]> writes: > > I recently got a rather interesting Debian bug [1]: When upgrading a > > pre-8.1 database to 8.1, the upgrade messes up permissions if the old > > database had users and groups with the same name. Since in 8.1 they > > get collapsed to a 'role' there will be a name clash. > > I think the only real problem here is that the role ends up with > NOLOGIN set, which we could probably fix by reordering the commands; It will also lead to confusion, especially if the user is not in the group with the same name. If the admin assigned different privileges to the group and to the user, then collapsing them into one role would change the privileges for the members of the group, or not? > but of course we can't do anything about dumps made with existing > versions of pg_dump. At least in Debian the upgrade process always uses the latest pg_dumpall. > > My current solution checks for this situation and aborts the upgrade > > That seems like serious overkill. Since I currently do not know any other clean way, it seemed like a safe choice to me for now. The script just aborts and asks the admin to rename the affected user or groups, and then reattempt the upgrade. What would you recommend instead? Thanks, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developerhttp://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] Upgrading from < 8.1 with users and groups with same name
Martin Pitt <[EMAIL PROTECTED]> writes: > Tom Lane [2005-12-29 22:20 -0500]: >> I think the only real problem here is that the role ends up with >> NOLOGIN set, which we could probably fix by reordering the commands; > It will also lead to confusion, especially if the user is not in the > group with the same name. If the admin assigned different privileges > to the group and to the user, then collapsing them into one role > would change the privileges for the members of the group, or not? It would, but that would have been a really confusing situation to start with. I'm not finding this a compelling concern. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] Log entry asking to contact support
Hi, I was running a manual vacuum through pgadmin 1.4.1 on a database and my connection to the database was lost during it. I reconnected to the database, went to Tools->Server Status->Log File and there is an entry that says: "This application has requested the Runtime to terminate in an unusual way. Please contact the application's support team for more information". I am running XP Pro SP2. Database is 8.1.1 and is not located on the same machine. I also have autovacuum enabled. I then tried to re-vacuum the database by using the local copy of pgadmin on the database machine. When it got to the same table and began working it stopped again. This time an error message was displayed instead of the connection being closed. The error: "failed to re-find parent key in "idx_volume_consultant" Should I just recreate the index and try to vacuum (full) again? I want to assume it got corrupted during the original vacuum attempt. I have been starting the vacuum from the database name level in pgadmin. I would be happy to try and give more info if I can. I initially posted this to pgadmin-support but was asked to post here. Mike ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] COPY TO STDOUT BINARY
Andreas Pflug wrote: > Tom Lane wrote: > > Andreas Pflug <[EMAIL PROTECTED]> writes: > > > >>Is COPY foo TO STDOUT BINARY supposed to work? > > > > > > I don't think psql will do anything particularly sane with binary copy > > data, if that's what you meant. > > echo "COPY foo TO STDOUT BINARY;" | psql >bar > > writes a 0 bytes file; not surprised if psql doesn't act sanely in > interactive mode. > > For testing, I changed slony to use COPY .. BINARY, same result. I tested this in a stand-alone backend and saw binary output that looked right, so I think it is only psql that is failing. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #2136: plperl doesn't work, plperlu - yes
The following bug has been logged online: Bug reference: 2136 Logged by: Robert Osowiecki Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.1 Operating system: Linux 2.6.14-gentoo-r5 #2 SMP Thu Dec 22 11:58:01 CET 2005 i686 Intel(R) Xeon(TM) CPU 3.20GHz GenuineIntel GNU/Linux Description:plperl doesn't work, plperlu - yes Details: Creation of any plperl function gives error message: ERROR: creation of Perl function failed: Can't locate object method "new" via package "Safe" at line 1. (in cleanup) Can't call method "reval" on an undefined value at line 1. The same function created in plperlu language compiles and works fine. I've recompiled Postgres to be sure about library versions. Perl version: v5.8.6 built for i686-linux ldd output: #ldd /opt/pgsql/lib/plperl.so linux-gate.so.1 => (0xe000) libperl.so.1 => /usr/lib/perl5/5.8.6/i686-linux/CORE/libperl.so.1 (0xb7e6f000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7e19000) libnsl.so.1 => /lib/libnsl.so.1 (0xb7e04000) libdl.so.2 => /lib/libdl.so.2 (0xb7e0) libm.so.6 => /lib/libm.so.6 (0xb7ddd000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7daf000) libutil.so.1 => /lib/libutil.so.1 (0xb7daa000) libc.so.6 => /lib/libc.so.6 (0xb7c92000) /lib/ld-linux.so.2 (0x8000) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #2135: system error 182 while loading ODBC driver
The following bug has been logged online: Bug reference: 2135 Logged by: Carlos del Cacho Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.1 Operating system: Win2k Description:system error 182 while loading ODBC driver Details: I am using the win32 binary downloaded from this site. If I write a simple ODBC standalone program that does a query to a database, it works ok. However, if I try to use the GEOS library in the same program (from FWTools1.0.0a7) to parse WKT output from PostGIS, the driver does not connect and fails with system error 182. Could this be a DLL incompatibility issue? PostGIS also uses GEOS, I ignore if this could be causing the problem. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #2137: CREATE DATABASE permission is not inherited.
The following bug has been logged online:
Bug reference: 2137
Logged by: Chander Ganesan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.1
Operating system: SLES 9 - linux 2.6.5-7.97-default #1 Fri Jul 2 14:21:59
UTC 2004 i686 i686 i386 GNU/Linux
Description:CREATE DATABASE permission is not inherited.
Details:
Apparently one needs to do a 'set role' in order to gain access to a 'create
database' privilege, even though inherit is set to "true" for the user.
This is contrary to the documentation - which implies that ineritance is
automatic.
Access privileges (granted with GRANT) seem to flow down correctly.
This could be a documentation issue...
payroll=> select session_user, current_user;
session_user | current_user
--+--
joe | joe
(1 row)
payroll=> \x
Expanded display is on.
payroll=> select * from pg_roles where rolname in ('joe', 'dba');
-[ RECORD 1 ]-+-
rolname | dba
rolsuper | f
rolinherit| t
rolcreaterole | f
rolcreatedb | t
rolcatupdate | f
rolcanlogin | f
rolconnlimit | -1
rolpassword |
rolvaliduntil |
rolconfig |
oid | 16515
-[ RECORD 2 ]-+-
rolname | joe
rolsuper | f
rolinherit| t
rolcreaterole | f
rolcreatedb | f
rolcatupdate | f
rolcanlogin | t
rolconnlimit | -1
rolpassword |
rolvaliduntil |
rolconfig | {search_path=public}
oid | 16516
payroll=> \du
List of roles
Role name | Superuser | Create role | Create DB | Connections | Member
of
---+---+-+---+-+
---
accounting| no| no | no| no limit|
dba | no| no | yes | no limit|
joe | no| no | no| no limit| {dba}
manufacturing | no| no | no| no limit|
payroll | no| no | no| no limit|
postgres | yes | yes | yes | no limit|
root | yes | no | no| no limit|
student | no| no | no| no limit|
student1 | no| yes | no| no limit|
(9 rows)
payroll=> create database test;
ERROR: permission denied to create database
payroll=> set role dba;
SET
payroll=> create database test;
ERROR: database "test" already exists
payroll=> drop database test;
DROP DATABASE
payroll=> reset role;
RESET
payroll=> create database test;
ERROR: permission denied to create database
payroll=> set role dba;
SET
payroll=> create database test;
CREATE DATABASE
payroll=> select version();
-[ RECORD 1
]---
-
version | PostgreSQL 8.1.1 on i686-pc-linux-gnu, compiled by GCC gcc (GCC)
3.3.3 (SuSE Linux)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2102: Backend reports wrong number of affected rows for a
Well, you'll see the status of the last UPDATE executed due to a rule ... but that doesn't mean it couldn't have updated zero rows. It might be worth pointing out here that conditional rules insert queries that have the condition added to their WHERE clause; if the condition is false then no rows are going to get processed. Thanks for the additional insight. Then everything is working as it should. Thanks for your help. Brent
