[BUGS] BUG #2745: upgrade.bat refers to msi file name for version 8.1 ms
The following bug has been logged online: Bug reference: 2745 Logged by: Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 beta Operating system: windows xp Description:upgrade.bat refers to msi file name for version 8.1 ms Details: The last line should be msiexec /i postgresql-8.2beta2-int.msi REINSTALLMODE=vamus REINSTALL=ALL /qr or you can set a variable called say POSTGRES with POSTGRES having value of the msi file name. then msiexec just use that variable. ---(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] JDBC driver bug PreparedStatement.setNull(int,Types.BOOLEAN)
the JDBC driver does not handle setNull for boolean types. the switch statement in setNull should be expanded with a case that checks for Types.BOOLEAN
[BUGS] BUG #2742: psql -c is not case sensitive
The following bug has been logged online: Bug reference: 2742 Logged by: Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0rc5 Operating system: Linux Red Hat 8 Description:psql -c is not case sensitive Details: psql -c is not case sensitive... If a schema is created with the command psql -d dbname -c "CREATE SCHEMA "SCHEMA_name" and is executed at the command line, then a schema is created for dbname with the name schema_name. If a schema is created with the commands psql dbname CREATE SCHEMA "SCHEMA_name"; and is executed from the psql command, then a schema is created for dbname with the name SCHEMA_name. Does this appear to be a bug? ---(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 #2750: information_schema broken with primary and foreign key on the same column
The following bug has been logged online: Bug reference: 2750 Logged by: Stephen haberman Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 beta 3 Operating system: win32 Description:information_schema broken with primary and foreign key on the same column Details: Just tried postgresql 8.2 beta 3 and it is missing a patch I had sent to pgsql-patches after trying 8.2 beta 2 a few weeks ago. The information_schema `position_in_unique_constraint` is broken when a column has both a primary key and a foreign key. Both constraints match in the `SELECT a FROM generate_series` and caused a "subquery returns multiple results for an expression" error. (Or something like that--I don't have the exact error message handy.) This patch fixes it: --- information_schema-original.sql Tue Oct 24 11:10:16 2006 +++ information_schema.sql Fri Oct 27 02:24:52 2006 @@ -928,6 +928,7 @@ (SELECT a FROM generate_series(1, array_upper(ss.confkey,1)) a) AS foo WHERE conrelid = ss.confrelid AND conkey[foo.a] = ss.confkey[(ss.x).n] + AND contype = 'f' ) AS position_in_unique_constraint FROM pg_attribute a, (SELECT r.oid, r.relname, nc.nspname AS nc_nspname, ---(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 #2741: Double-free on error in ECPGconnect
The following bug has been logged online:
Bug reference: 2741
Logged by: Peter Harris
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1 and earlier
Operating system: Linux
Description:Double-free on error in ECPGconnect
Details:
When using more than one database connection with ECPG, you might have
obtained and freed blocks of data on one connection before trying to open
the other.
If the second connection fails, ECPGraise will be called and call
ECPGfree_auto_mem. This can cause an invalid free() of a pointer you've
already freed.
==
/*
demonstrate "double free on connection error" bug in libecpg
build:
ecpg bug.pgc
gcc -o bug bug.c -lecpg
test:
valgrind ./bug
to show what happens if you do ECPGclear_auto_mem, gcc -D FIX
*/
#ifdef FIX
extern void ECPGclear_auto_mem(void);
#endif
EXEC SQL INCLUDE sqlca;
EXEC SQL WHENEVER SQLERROR CONTINUE;
int main(int argc, char **argv)
{
EXEC SQL BEGIN DECLARE SECTION;
const char **anything=NULL;
EXEC SQL END DECLARE SECTION;
/* first connection, should be OK */
EXEC SQL CONNECT TO template1 AS ok_cnx;
/* get some stuff, doesn't matter what */
EXEC SQL AT ok_cnx SELECT datname INTO :anything FROM pg_database;
/* free it */
free(anything);
#ifdef FIX
ECPGclear_auto_mem();
#endif
/* second connection to nonexistent database */
EXEC SQL CONNECT TO no_such_database AS crash_cnx;
return 0;
}
==
ECPGconnect should call ECPGclear_auto_mem, just as
ECPGdo does. Patch will be posted soon...
Peter Harris
---(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 #2744: pg_dump, ERROR: out of memory, Failed on request of size 270344621
The following bug has been logged online: Bug reference: 2744 Logged by: aTz Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.5 (Release) Operating system: FreeBSD 6.1-RELEASE Description:pg_dump, ERROR: out of memory, Failed on request of size 270344621 Details: Hello! Sorry for english. I have a database with table "documents", that have column type "bytea". Database size is ~1.5 GB (99% of objects is images, documents, pdf's in bytea fields, middle size of each object ~ 20Mb). Database initialized: initdb --encoding=UTF8 --locale=ru_RU.UTF-8 SysV kernel: kern.ipc.msgmax: 16384 kern.ipc.msgmni: 40 kern.ipc.msgmnb: 2048 kern.ipc.msgtql: 40 kern.ipc.msgssz: 8 kern.ipc.msgseg: 2048 kern.ipc.semmap: 128 kern.ipc.semmni: 64 kern.ipc.semmns: 1024 kern.ipc.semmnu: 30 kern.ipc.semmsl: 128 kern.ipc.semopm: 100 kern.ipc.semume: 10 kern.ipc.semusz: 92 kern.ipc.semvmx: 32767 kern.ipc.semaem: 16384 kern.ipc.shmmax: 268435456 kern.ipc.shmmin: 1 kern.ipc.shmmni: 128 kern.ipc.shmseg: 64 kern.ipc.shmall: 65536 When i try to dump database: pg_dump --encoding=WIN1251 -U postgres docs > docs.sql It failed with message: === pg_dump: ERROR: out of memory DETAIL: Failed on request of size 270344621. pg_dump: SQL-команда по вÑгÑÑзке ÑодеÑжимого ÑаблиÑÑ "documents" не ÑдалаÑÑ: PQendcopy() вÑполнилаÑÑ Ð½ÐµÐ½Ð¾ÑмалÑно. pg_dump: Ðоманда бÑла: COPY public.documents (id, project_id, doc_group_id, is_archive, title, status, version, modified, description, filedata, filename, filet ype, filesize) TO stdout; In log file: TopMemoryContext: 65176 total in 6 blocks; 4544 free (15 chunks); 60632 used Record information cache: 8192 total in 1 blocks; 1864 free (0 chunks); 6328 used Type information cache: 8192 total in 1 blocks; 1864 free (0 chunks); 6328 used Operator class cache: 8192 total in 1 blocks; 4936 free (0 chunks); 3256 used TopTransactionContext: 8192 total in 1 blocks; 7496 free (3 chunks); 696 used MessageContext: 8192 total in 1 blocks; 5480 free (1 chunks); 2712 used CFuncHash: 8192 total in 1 blocks; 4936 free (0 chunks); 3256 used smgr relation table: 8192 total in 1 blocks; 1840 free (0 chunks); 6352 used Portal hash: 8192 total in 1 blocks; 3912 free (0 chunks); 4280 used PortalMemory: 8192 total in 1 blocks; 8040 free (0 chunks); 152 used PortalHeapMemory: 67206196 total in 7 blocks; 29936 free (22 chunks); 67176260 used COPY TO: 90785952 total in 3 blocks; 7240 free (6 chunks); 90778712 used Relcache by OID: 8192 total in 1 blocks; 3376 free (0 chunks); 4816 used CacheMemoryContext: 1040384 total in 7 blocks; 294304 free (1 chunks); 746080 used pg_toast_16443_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_description_o_c_o_index: 1024 total in 1 blocks; 256 free (0 chunks); 768 used pg_database_oid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_largeobject_loid_pn_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_trigger_oid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_trigger_tgconstrrelid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_trigger_tgconstrname_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_attrdef_oid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_cast_oid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_rewrite_oid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_attrdef_adrelid_adnum_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_depend_reference_index: 1024 total in 1 blocks; 256 free (0 chunks); 768 used pg_depend_depender_index: 1024 total in 1 blocks; 256 free (0 chunks); 768 used pg_tablespace_spcname_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_tablespace_oid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_constraint_oid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_constraint_contypid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_constraint_conrelid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_constraint_conname_nsp_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_index_indrelid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_roles: 7168 total in 3 blocks; 2824 free (0 chunks); 4344 used pg_type_typname_nsp_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_type_oid_index: 1024 total in 1 blocks; 392 free (0 chunks); 632 used pg_trigger_tgrelid_tgname_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_statistic_relid_att_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_auth_members_member_role_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_auth_members_role_member_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used pg_rewrite_rel_rulename_index: 1024 total in 1 blocks; 328 free (0 chunks); 696 used
[BUGS] BUG #2749: Function's final statement must be a SELECT
The following bug has been logged online: Bug reference: 2749 Logged by: Hagen Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2beta2 Operating system: OSX Description:Function's final statement must be a SELECT Details: create function test(text) returns table as $sql$ insert into table(value) values($1) returning *; $sql$ language sql; really should work now, instead I get: PGError: ERROR: return type mismatch in function declared to return table DETAIL: Function's final statement must be a SELECT. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2742: psql -c is not case sensitive
"" <[EMAIL PROTECTED]> writes: > If a schema is created with the command > psql -d dbname -c "CREATE SCHEMA "SCHEMA_name" > and is executed at the command line, then a schema is created for dbname > with the name schema_name. I think you need to reflect on the properties of the shell's quoting conventions --- that will come through to psql and hence the backend with no quotes. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2749: Function's final statement must be a SELECT
"Hagen" <[EMAIL PROTECTED]> writes: > create function test(text) returns table as $sql$ > insert into table(value) values($1) returning *; > $sql$ language sql; > really should work now, No doubt, but it's not happening for 8.2. See thread here: http://archives.postgresql.org/pgsql-hackers/2006-10/msg00665.php There's a lot more to it than meets the eye :-( regards, tom lane ---(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
