[BUGS] BUG #4646: Default password is patently absurd
The following bug has been logged online: Bug reference: 4646 Logged by: Jason Email address: jdmarsh...@gmail.com PostgreSQL version: 8.2 Operating system: Windows XP Description:Default password is patently absurd Details: I let the installer pick a password for me. What it picked was 31 characters long, and included characters that I can't actually type on my keyboard. Quite possibly some can't even be displayed on my system, as several are listed as "?". One of the other characters is the section symbol (aka §) Who thought this was a good idea? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] createlang
postgres@abigail ~/data $ createdb test1 Password: CREATE DATABASE postgres@abigail ~/data $ createlang --dbname=test1 --pglib=/usr/lib/pgsql 'plpgsql' Password: Password: Password: Password: postgres@abigail ~/data $ createlang --list --dbname=test1 Password: Procedural languages Name | Trusted? | Compiler -+--+-- plpgsql | t| PL/pgSQL (1 row) postgres@abigail ~/data $ dropdb test1 Password: DROP DATABASE - - The createlang does not accept my password correctly. Also, should it not give a confirmation such as "CREATE" when it executes? One can see from the above output that I had to enter it 4 times. Note that it does not behave this way when I enter the incorrect password (see below). I'm on RedHat 7.1 and using the default Postgres RPM from my initial install. template1=# SELECT version() template1-# ; version - PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc 2.96 (1 row) postgres@abigail ~/data $ cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 393175040 219648000 173527040 1470464 32092160 80633856 Swap: 2713927680 271392768 - - postgres@abigail ~/data $ createdb test1 Password: CREATE DATABASE postgres@abigail ~/data $ createlang --dbname=test1 --pglib=/usr/lib/pgsql 'plpgsql' Password: psql: Password authentication failed for user 'postgres' createlang: external error postgres@abigail ~/data $ createlang --list --dbname=test1 Password: Procedural languages Name | Trusted? | Compiler --+--+-- (0 rows) postgres@abigail ~/data $ dropdb test1 Password: DROP DATABASE ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #3294: PostgreSQL Setting permissions for folders during installation then Crashing
The following bug has been logged online: Bug reference: 3294 Logged by: Jason Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4-1 Operating system: Windows XP Professional Description:PostgreSQL Setting permissions for folders during installation then Crashing Details: Running the installation, everything works fine until it starts copying files. Then it reaches a fatal error, and says: Failed to set permissions on the installed files. Please see the logfile in 'C:\Program Files\PostgreSQL\8.2\tmp\pgperm.log'. 8.2 then become a folder that I as administrator of the system do not have permissions to access. I can't get into the folder, I can't delete the folder. I can't do anything to it. The installer then rolls back and quits. I've tried this 3 times, and now have 3 different folders that I can't delete. Please help. --Jason ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] Too-large tuple corrupts tables
POSTGRESQL BUG REPORT TEMPLATE
Your name : Jason Holt
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : AMD K6-2
Operating System (example: Linux 2.0.26 ELF) : Linux (RedHat 5.2)
PostgreSQL version (example: PostgreSQL-6.5) : PostgreSQL-6.5
Compiler used (example: gcc 2.8.0) : gcc 2.7.2.3
Please enter a FULL description of your problem:
Certain sequences of insert / select statements of varying sizes
crash the backend and corrupt the table. From then on, select doesn't
work on that table, though usually it can be dropped. Occasionally the
backend will actually hang instead of dying.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
This perl code repeatably starts having trouble at this point when
starting from a newly created and vacuumed table foo( bar text );
...
7369
8369
DBD::Pg::st execute failed: ERROR: Tuple is too big: size 8408
52
1052
2052
3052
4052
Backend message type 0x44 arrived while idle
DBD::Pg::db selectrow_array failed: Backend message type 0x44 arrived
while idle
5052
DBD::Pg::st execute failed: PQsendQuery() -- There is no connection to the
backend.
DBD::Pg::db selectrow_array failed: PQsendQuery() -- There is no
connection to the backend.
...
Here's the (slow, storage-intensive) routine:
#!/usr/bin/perl
use DBI;
$dbh = DBI->connect('dbi:Pg:', 'jason', 'whatever', { AutoCommit => 1 })
or die "$DBI::errstr";
$sth = $dbh->prepare("insert into foo(bar) values(?)");
$| = 1;
for($i = 0 ; $i < 9000; $i++) {
# The script dies sooner or later depending on what you % by
$foo = 'x' x (($i * 1000) % 9317);
print length($foo), "\n";
$sth->execute($foo);
# Removing this line makes the script not fail
$bar = $dbh->selectrow_array('select * from foo');
}
If you know how this problem might be fixed, list the solution below:
-
[BUGS] pgsql-loophole-request@postgresql.org does not exist
http://www.postgresql.org/bugs/index.php indicates that the address [EMAIL PROTECTED] exists. It does not. ;-) The original message was received at Wed, 17 Jan 2001 19:00:28 -0500 (EST) from [209.43.202.2] - The following addresses had permanent fatal errors - <[EMAIL PROTECTED]> (reason: 550 5.1.1 User unknown) - Transcript of session follows - ... while talking to localhost: >>> RCPT To: <<< 550 5.1.1 User unknown 550 5.1.1 <[EMAIL PROTECTED]>... User unknown
[BUGS] regression failure: random
Version: cvs checkout -r REL7_1_BETA3 pgsql Platform: RedHat 6.2 Running the regression test: ./pg_regress --schedule=/path/src/test/regress/parallel_schedule --port=65432 --multibyte= numeric_big I encountered the following regression error. Rerunning the regression went fine. Given this is testing randomness, I can offer no other useful information. I do not understand the test so I am effectively "a dumb user". *** ./expected/random.out Wed Jan 10 01:05:43 2001 --- ./results/random.outWed Jan 17 15:35:38 2001 *** *** 31,35 WHERE random NOT BETWEEN 80 AND 120; random ! (0 rows) --- 31,36 WHERE random NOT BETWEEN 80 AND 120; random ! 124 ! (1 row) ==
[BUGS] [tim@perdue.net: Re: mysql2pgsql tool]
I'm trying to find the right people to send this bug report to, and Tim says you're the people, so... see attached email, please. -- - Jason Politicians are the same all over. They promise to build a bridge even where there is no river. -- Nikita Khrushchev --- Begin Message --- Thanks. I didn't create that tool - the postgres team did. Tim On Fri, Oct 05, 2001 at 09:27:32PM -0700, Jason Spence wrote: > Hi - > > I'm using your mysql2pgsql tool to migrate a database over to > PostgreSQL. Works great, except I had to do one thing: > > cat old-database.sql92 | sed -e 's/ TYPE=MyISAM//' -e 's/^#/--/' -e > 's/UNIQUE KEY/UNIQUE/' > output1.sql > > That takes care of the comments, the new suffix appended to each > CREATE TABLE clause, and a grammar difference in key declaration. > > There's also a problem with the UNIQUE clauses where MySQL wants an > index name before the parenthesized list of columns and PostgreSQL > just wants the list of columns immediately. I couldn't figure out how > to fix that in sed, but maybe you can. > > -- > - Jason > > "Well, if you can't believe what you read in a comic book, what *___can* > you believe?!" > -- Bullwinkle J. Moose [Jay Ward] -- Founder - PHPBuilder.com / Geocrawler.com / SourceForge Perdue, Inc. 515-554-9520 --- End Message --- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] BUG #2710: Intermittent hangs on sequence generation
The following bug has been logged online: Bug reference: 2710 Logged by: Jason Palmer Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: Redhat enterprise 4 Description:Intermittent hangs on sequence generation Details: We can't exactly pinpoint the cause for this so I submit the problem to the postgres community. We are currently running Postgres 8.1. Postgres is our main database engine and several of our applications connect to it including our java stack (tomkat 5.0.28 running java 1.4.2 struts) and Ruby on Rails (Rails 1.6 w/ ActiveRecord). What we experience is bizarre. We can always create tables with no sequences. But occasionally the database will hang when we attempt to create a table with a sequence or foreign key. We can cancel the operation and when it "hangs" the database will still be able to insert/update/delete/select records so it's not totally down. But we are required to reboot the database before we can successfully run the query. Again, this does not happen all the time, but we've found that it happens quite a lot. ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] initdb core dump
Hello, I am attempting to install PostgreSQL 7.3.1 for the first time on a Redhat 7.1 Linux box. I'm getting a core dump when I do the following. Any suggestions for things I should be checking, or is this a bug? Thanks, Jason [postgres@spiraltribe postgresql-7.3.1]$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data/ The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale en_US. This locale setting will prevent the use of indexes for pattern matching operations. If that is a concern, rerun initdb with the collation order set to "C". For more information see the Administrator's Guide. Fixing permissions on existing directory /usr/local/pgsql/data/... ok creating directory /usr/local/pgsql/data//base... ok creating directory /usr/local/pgsql/data//global... ok creating directory /usr/local/pgsql/data//pg_xlog... ok creating directory /usr/local/pgsql/data//pg_clog... ok creating template1 database in /usr/local/pgsql/data//base/1... /usr/local/pgsql/bin/initdb: line 582: 4373 Aborted (core dumped) "$PGPATH"/postgres -boot -x1 $PGSQL_OPT $BACKEND_TALK_ARG template1 initdb failed. [postgres@spiraltribe postgresql-7.3.1]$ ---(end of broadcast)--- TIP 3: 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] Cygwin PostgreSQL 7.4.1 rules regression test failure
POSTGRESQL BUG REPORT TEMPLATE Your name : Jason Tishler Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel Pentium Operating System (example: Linux 2.4.18) : Cygwin 1.5.5-1 PostgreSQL version (example: PostgreSQL-7.4.1): PostgreSQL-7.4.1 Compiler used (example: gcc 2.95.2) : gcc 3.3.1 (cygming special) Please enter a FULL description of your problem: PostgreSQL-7.4.1 fails the rules regression test with a diff such as the one posted to the pgsql-cygwin mailing list: http://archives.postgresql.org/pgsql-cygwin/2003-12/msg00088.php Note that I *cannot* reproduce this problem under PostgreSQL 7.4. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- The following assumes PostgreSQL has been built, installed, and running: $ # cd to where postgresql-7.4.1.tar.bz2 was extracted $ cd postgresql-7.4.1/src/test/regress $ make $ sed -n '1,/rules/p' serial_schedule >/tmp/rules_schedule $ ./pg_regress --schedule=/tmp/rules_schedule --multibyte=SQL_ASCII [snip] test rules... FAILED [snip] If you know how this problem might be fixed, list the solution below: - Sorry, I don't have any suggestions yet. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 3: 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
Re: [BUGS] Cygwin PostgreSQL 7.4.1 rules regression test failure
Peter, On Thu, Jan 08, 2004 at 09:47:27PM +0100, Peter Eisentraut wrote: > Jason Tishler wrote: > > PostgreSQL-7.4.1 fails the rules regression test with a diff such as > > the one posted to the pgsql-cygwin mailing list: > > > > http://archives.postgresql.org/pgsql-cygwin/2003-12/msg00088.php > > > > Note that I *cannot* reproduce this problem under PostgreSQL 7.4. > > I think this was already solved. Yes, did you see my post from yesterday? http://archives.postgresql.org/pgsql-cygwin/2004-01/msg00022.php > You are executing the 7.4.1 regression tests with a 7.4 server. No, I executing with a 7.4.1 server, but against a database created (i.e., initdb-ed) with 7.4. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] BUG #1545: LIBPQ Windows Version not calling WSACleanup for every WSAStartup
The following bug has been logged online: Bug reference: 1545 Logged by: Jason Erickson Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1,7.4.7 Operating system: Windows Description:LIBPQ Windows Version not calling WSACleanup for every WSAStartup Details: Taken from microsoft at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/win sock/wsastartup_2.asp --- An application must call one WSACleanup call for every successful WSAStartup call to allow third-party DLLs to make use of a WS2_32.DLL on behalf of an application. This means, for example, that if an application calls WSAStartup three times, it must call WSACleanup three times. The first two calls to WSACleanup do nothing except decrement an internal counter; the final WSACleanup call for the task does all necessary resource deallocation for the task. -- The only place WSACleanup is being called is libpqdll when the process detaches the DLL (if the libpq is not staticly linked in), which matches up with the WSAStartup when the process attaches to the DLL. The WSAStartup in the fe-connect.c->makeEmptyPGconn() does not have a matching WSACleanup. WSACleanup could possibly be placed in freePGconn(), but unsure if all possible error cases will go through this function. This problem exists in both 8.0.1 and 7.4.7 of the libpq interface for Windows. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] BUG #2439: pgAdmin III v1.4.1 fails to compile with GCC 4.1.0
The following bug has been logged online: Bug reference: 2439 Logged by: Jason Kankiewicz Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: Gentoo Linux ~amd64 Description:pgAdmin III v1.4.1 fails to compile with GCC 4.1.0 Details: "emerge =pgadmin3-1.4.1" produces the following errors with GCC 4.1.0: pgadmin3-1.4.1/src/include/pgSchema.h:88: error: extra qualification 'pgSchemaObject::' on member 'pgSchemaObject' pgadmin3-1.4.1/xtra/pgagent/include/connection.h:44: extra qualification 'DBConn::' on member 'DBConn' Removing the extra qualifications allows the build to succeed. ---(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
