Re: [BUGS] BUG #6261: 35.9. C-Language Functions
On Wed, Oct 19, 2011 at 3:43 AM, guenter abraham wrote: > > The following bug has been logged online: > > Bug reference: 6261 > Logged by: guenter abraham > Email address: abra...@itbb.de > PostgreSQL version: 9.1 > Operating system: win 7 prof /64 > Description: 35.9. C-Language Functions > Details: > > the import of C-Language Functions (Version 0 and Version 1 as described in > chapter 35.9 of the manual) leads to an "unknown-error" > > create function aktualisiere_client(int4,int4,int4) > returns int4 as > 'db_sock.dll','aktualisiere_client' > language 'C' volatile strict; > > > > > FEHLER: konnte Bibliothek »C:/Program > Files/PostgreSQL/9.1/lib/db_sock.dll« nicht laden: unknown error 193 > > > ** Fehler ** > > FEHLER: konnte Bibliothek »C:/Program > Files/PostgreSQL/9.1/lib/db_sock.dll« nicht laden: unknown error 193 > SQL Status:58P01 > > -- > this dll works fine under Vers 8.2. I recompiled it with mingw / gcc Without more details it's pretty hard to speculate on what the problem might be here. I'm pretty doubtful that this is broken in general, as that would mean that most of the extensions we bundle with core would be broken on Windows, and I think someone would have noticed that by now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL 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] 'pg_ctl restart' confused about pathname to postgresql.conf
I've noticed that I occasionally see errors from "pg_ctl restart" claiming: postgres cannot access the server configuration file ... No such file or directory depending on what directory I execute "pg_ctl restart" from, and where the postmaster was originally started from. I boiled this problem down to the attached test case. I've seen this problem on 9.1.1 and git head. The testcase was tried on OS X and Debian, with Postgres installed locally like this: ./configure --prefix=/home/postgres/runtime/ --with-python --enable-debug You can run the test case stand-alone, though it's probably easier to see what's going on if you just copy-paste into your terminal: at the end you should wind up with your current directory "/tmp/foo/". You should see that the last command, "pg_ctl -D $DATADIR restart" failed to start the server back up, complaining: postgres cannot access the server configuration file "/tmp/foo/baz/postgresql.conf": No such file or directory even though $DATADIR is clearly set to "/tmp/foo/bar/baz/" (N.B. directory "bar" has gone missing in the above error message). A "pg_ctl -D $DATADIR start" should work at this point, though. This seems like some bug in normalizing the absolute path to postgresql.conf. Josh pg_ctl_weirdness.sh Description: Bourne shell script -- 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 #6264: Superuser does not have inherent Replication permission
The following bug has been logged online: Bug reference: 6264 Logged by: Keith Fiske Email address: ke...@omniti.com PostgreSQL version: 9.1.1 Operating system: Debian Description:Superuser does not have inherent Replication permission Details: Was testing out an upgrade from 9.0.4 to 9.1.1 and ran across either some lack of clarity in the documentation or a bug in the superuser privilege. I had a streaming replication setup and after the upgrade and setting up the new slave, the slave would no longer connect to the master for SR. Looking into this more, I saw that 9.1 has a new Replication permission to allow non-superusers the ability to be replication users. The documentation says replication is inherent to a superuser. After testing several times, I can assure you it is not. The old replication user from 9.0.4 which was carried through the upgrade kept its superuser privileges, but was unable to be used for replication until I explicitly granted it the Replication permission. Brand new roles created initially as superusers are explicitly given the separate replication permission. If you create a user as a NONsuperuser, then later ALTER them to be one, they will NOT have the replication permission and cannot be used as a replication user until you explicitly grant that permission. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
