|
|
[BUGS] ON DELETE SET NULL clauses do error when more than two columns are referenced to one table
By Pavel Stehule at Aug 14, 2007, 7:12 pm UTC
Hello One question on www.abclinuxu.cz signalise bug in PostgreSQL RI implementation. Detected on 8.0.x and verified on 8.3. Regards Pavel Stehule CREATE TABLE users ( id integer NOT NULL, name VARCHAR NOT NULL, PRIMARY KEY (id) INSERT INTO users VALUES (1, 'Jozko'); INSERT INTO users VALUES (2,... More...
Hello
One question on www.abclinuxu.cz signalise bug in PostgreSQL RI
implementation. Detected on 8.0.x and verified on 8.3.
Regards
Pavel Stehule
CREATE TABLE users (
id integer NOT NULL,
name VARCHAR NOT NULL,
PRIMARY KEY (id)
);
INSERT INTO users VALUES (1, 'Jozko');
INSERT INTO users VALUES (2, 'Ferko');
INSERT INTO users VALUES (3, 'Samko');
CREATE TABLE tasks (
id integer NOT NULL,
owner INT REFERENCES users (id) ON UPDATE CASCADE ON DELETE SET NULL,
worker INT REFERENCES users (id) ON UPDATE CASCADE ON DELETE SET NULL,
checked_by INT REFERENCES users (id) ON UPDATE CASCADE ON DELETE SET NULL,
PRIMARY KEY (id)
);
INSERT INTO tasks VALUES (1,1,NULL,NULL);
INSERT INTO tasks VALUES (2,2,2,NULL);
INSERT INTO tasks VALUES (3,3,3,3);
DELETE FROM users WHERE id = 1; -- works simple
DELETE FROM users WHERE id = 2; -- works ok
DELETE FROM users WHERE id = 3; -- doesn't work, why?
ERROR: insert or update on table "tasks" violates foreign key
constraint "tasks_checked_by_fkey"
DETAIL: Key (checked_by)=(3) is not present in table "users".
CONTEXT: SQL statement "UPDATE ONLY "public"."tasks" SET "worker" =
NULL WHERE $1 OPERATOR(pg_catalog.=) "worker""
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [email protected: majo...@postgresql.org] so that your
message can get through to the mailing list cleanly
6 Replies
|
|
|
[BUGS] failed to re-find parent key in "..." for deletion target page
By Brian Hirt at Aug 13, 2007, 1:43 pm UTC
--Apple-Mail-8--351357693 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I was doing some testing with tsearch2 on my dev box and I've run across this problem. I created the tsvector and added the trigger and then i was updating the entire table... More...
--Apple-Mail-8--351357693
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
I was doing some testing with tsearch2 on my dev box and I've run
across this problem.
I created the tsvector and added the trigger and then i was updating
the entire table to populate the ixdfti field. When i was done, I
was unable to vacuum the table, I get this error. Any ideas an
what's going on? I've shutdown the database and made a tar of it
incase there is additional info you need.
basement_dev=# update developer_name set developer_id = developer_id;
UPDATE 262083
basement_dev=# VACUUM FULL developer_name;
ERROR: failed to re-find parent key in
"developer_name_developer_name" for deletion target page 163
basement_dev=# \d developer_name;
Table
"public.developer_name"
Column | Type
| Modifiers
-------------------+------------------------
+-----------------------------------------------------------------------
-----
developer_name_id | integer | not null default nextval
('developer_name_developer_name_id_seq'::regclass)
developer_id | integer | not null
developer_name | character varying(255) | not null
idxfti | tsvector |
t | text |
idxfti2 | tsvector |
Indexes:
"developer_name_pkey" PRIMARY KEY, btree (developer_name_id)
"developer_name_developer_id" btree (developer_id)
"developer_name_developer_name" btree (developer_name)
Triggers:
tsvectorupdate BEFORE INSERT OR UPDATE ON developer_name FOR
EACH ROW EXECUTE PROCEDURE tsearch2('idxfti', 'developer_name')
basement_dev=# select version();
version
------------------------------------------------------------------------
----------------------------------------------------------------
PostgreSQL 8.2.4 on i386-apple-darwin8.9.1, compiled by GCC i686-
apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5341)
(1 row)
--Apple-Mail-8--351357693
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1
<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">I was doing some testing with =
tsearch2 on my dev box and I've run across this problem.=A0 =A0<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>I created the tsvector and =
added the trigger and then i was updating the entire table to populate =
the ixdfti field.=A0 =A0When i was done,=A0I was unable to vacuum the =
table, I get this error.=A0 =A0Any ideas an what's going on?=A0 I've =
shutdown the database and made a tar of it incase there is additional =
info you need.=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><DIV>basement_dev=3D# =
update developer_name set developer_id =3D =
developer_id;</DIV><DIV>UPDATE 262083</DIV><DIV>basement_dev=3D# VACUUM =
FULL developer_name;</DIV><DIV>ERROR:=A0 failed to re-find parent key in =
"developer_name_developer_name" for deletion target page =
163</DIV><DIV>basement_dev=3D# \d developer_name;</DIV><DIV>=A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 Table "public.developer_name"</DIV><DIV>=A0 =A0 =A0 Column=A0 =A0 =
=A0=A0 |=A0 =A0 =A0 =A0 =A0 Type=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 Modifiers=A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
</DIV><DIV>-------------------+------------------------+------------------=
----------------------------------------------------------</DIV><DIV> =
developer_name_id | integer=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | not null =
default =
nextval('developer_name_developer_name_id_seq'::regclass)</DIV><DIV> =
developer_id=A0 =A0 =A0 | integer=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | not =
null</DIV><DIV> developer_name=A0 =A0 | character varying(255) | not =
null</DIV><DIV> idxfti=A0 =A0 =A0 =A0 =A0 =A0 | tsvector=A0 =A0 =A0 =A0 =
=A0 =A0 =A0=A0 | </DIV><DIV> t=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | text=A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | </DIV><DIV> idxfti2=A0 =A0 =A0 =A0 =
=A0=A0 | tsvector=A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | =
</DIV><DIV>Indexes:</DIV><DIV>=A0 =A0 "developer_name_pkey" PRIMARY KEY, =
btree (developer_name_id)</DIV><DIV>=A0 =A0 =
"developer_name_developer_id" btree (developer_id)</DIV><DIV>=A0 =A0 =
"developer_name_developer_name" btree =
(developer_name)</DIV><DIV>Triggers:</DIV><DIV>=A0 =A0 tsvectorupdate =
BEFORE INSERT OR UPDATE ON developer_name FOR EACH ROW EXECUTE PROCEDURE =
tsearch2('idxfti', 'developer_name')</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>basement_dev=3D# select =
version();</DIV><DIV>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 version=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 =
</DIV><DIV>---------------------------------------------------------------=
-------------------------------------------------------------------------<=
/DIV><DIV> PostgreSQL 8.2.4 on i386-apple-darwin8.9.1, compiled by GCC =
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build =
5341)</DIV><DIV>(1 row)</DIV><DIV><BR><DIV> <SPAN =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><SPAN =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><SPAN =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 13px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; =
"></SPAN></SPAN></SPAN></DIV><BR></DIV></DIV></BODY></HTML>=
--Apple-Mail-8--351357693--
3 Replies
|
|
|
[BUGS] BUG #3512: buggy install + no manual support
By Lamia Jackson at Aug 10, 2007, 9:38 pm UTC
The following bug has been logged online: Bug reference: 3512 Logged by: Lamia Jackson Email address: jimbosoak@yahoo.com PostgreSQL version: 8.2.4.1 Operating system: win32 Description: buggy install + no manual support Details: before completing installation i recieve an installer exception that... More...
The following bug has been logged online:
Bug reference: 3512
Logged by: Lamia Jackson
Email address: [email protected: jimb...@yahoo.com]
PostgreSQL version: 8.2.4.1
Operating system: win32
Description: buggy install + no manual support
Details:
before completing installation i recieve an installer exception that
packages (PostGIS, PL/Java, Slony-I) couldn't be activated. how could i
activate them manually and test that i'm sure that i done that. Probable for
all reason might be changing pgsql port from 5432
and very important for me. i'dont see an chapter in a manual that tell's me
how could i execute manually an SQL script for additional templates that
could be called per base needs. I left only Adminpack (preselected one) in
hope that the rest of them could easily be scripted if i need them in
creating a new database.
3 Replies
|
|
|
[BUGS] BUG #3532: Can't rollup array of arrays
By James William Pye at Aug 10, 2007, 6:26 pm UTC
The following bug has been logged online: Bug reference: 3532 Logged by: James William Pye Email address: pgsql@jwp.name PostgreSQL version: 8.2 Operating system: FreeBSD Description: Can't rollup array of arrays Details: Dunno about the spec, but I would think this should work:... More...
The following bug has been logged online:
Bug reference: 3532
Logged by: James William Pye
Email address: [email protected: p...@jwp.name]
PostgreSQL version: 8.2
Operating system: FreeBSD
Description: Can't rollup array of arrays
Details:
Dunno about the spec, but I would think this should work:
tinman@localhost/tinman[]=# SELECT array(select array[table_name,
column_name] FROM information_schema.columns LIMIT 10);
ERROR: could not find array type for datatype character varying[]
tinman@localhost/tinman[]=# SELECT version();
version
----------------------------------------------------------------------------
--------------------
PostgreSQL 8.2.4 on i386-portbld-freebsd6.2, compiled by GCC cc (GCC) 3.4.6
[FreeBSD] 20060305
(1 row)
The expectation is the production of an array like:
'{{table_foo,column_bar},{table_foo,column_bar2},...}'.
No? (yeah, it may be more of a feature request than a bug)
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
0 Replies
|
|
|
[BUGS] BUG #3523: plpython crash
By Julian at Aug 10, 2007, 03:18 am UTC
The following bug has been logged online: Bug reference: 3523 Logged by: Julian Email address: julan@internode.on.net PostgreSQL version: 8.2.4 Operating system: Linux Description: plpython crash Details: -- PostgreSQL 8.2.4 on x86_64-pc-linux-gnu, compiled by GCC x86_64-pc-linux-gnu-gcc (GCC)... More...
The following bug has been logged online:
Bug reference: 3523
Logged by: Julian
Email address: [email protected: j...@internode.on.net]
PostgreSQL version: 8.2.4
Operating system: Linux
Description: plpython crash
Details:
-- PostgreSQL 8.2.4 on x86_64-pc-linux-gnu, compiled by GCC
x86_64-pc-linux-gnu-gcc (GCC) 4.1.2 (Gentoo 4.1.2)
--see if this crashes for you.
BEGIN;
CREATE FUNCTION pyfunction(tuple record)
RETURNS "void"
LANGUAGE "plpythonu"
AS
$$
$$
;
CREATE FUNCTION mytrigger ()
RETURNS "trigger"
LANGUAGE "plpgsql"
AS
$$
BEGIN
PERFORM pyfunction(NEW);
END;
$$
;
CREATE TABLE mytable (mycol text) ;
CREATE TRIGGER mytrigger
AFTER INSERT
ON mytable
FOR EACH ROW
EXECUTE PROCEDURE mytrigger();
INSERT INTO mytable SELECT 'test';
ROLLBACK;
---------------------BACKTRACE------------------------
LOG: database system was interrupted at 2007-08-09 03:17:53 EST
LOG: checkpoint record is at 0/5471B260
LOG: redo record is at 0/5471B260; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 0/196948; next OID: 608885
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: redo starts at 0/5471B2B0
LOG: unexpected pageaddr 0/51862000 in log file 0, segment 84, offset
8790016
LOG: redo done at 0/54861E68
LOG: database system is ready
*** glibc detected *** postgres: test test2 [local] INSERT: double free or
corruption (out): 0x00002b7d14e40a30 ***
======= Backtrace: =========
/lib/libc.so.6[0x2b7d14c74b1d]
/lib/libc.so.6(__libc_free+0x76)[0x2b7d14c76146]
/usr/lib64/postgresql/plpython.so[0x2b7d16f32870]
/usr/lib64/postgresql/plpython.so[0x2b7d16f32a77]
/usr/lib64/postgresql/plpython.so(plpython_call_handler+0xbd)[0x2b7d16f3416d
]
postgres: test test2 [local] INSERT(ExecMakeFunctionResult+0xfd)[0x4ff0dd]
postgres: test test2 [local] INSERT(ExecProject+0x1c1)[0x4fd971]
postgres: test test2 [local] INSERT(ExecResult+0x63)[0x50d473]
postgres: test test2 [local] INSERT(ExecProcNode+0xc6)[0x4fd176]
postgres: test test2 [local] INSERT(ExecutorRun+0x10a)[0x4fc47a]
postgres: test test2 [local] INSERT[0x5130cb]
postgres: test test2 [local] INSERT(SPI_execute_plan+0xad)[0x51332d]
/usr/lib64/postgresql/plpgsql.so[0x2b7d16e1c310]
/usr/lib64/postgresql/plpgsql.so[0x2b7d16e1ee43]
/usr/lib64/postgresql/plpgsql.so[0x2b7d16e1e48a]
/usr/lib64/postgresql/plpgsql.so(plpgsql_exec_trigger+0x358)[0x2b7d16e20448]
/usr/lib64/postgresql/plpgsql.so(plpgsql_call_handler+0x152)[0x2b7d16e17c92]
postgres: test test2 [local] INSERT[0x4e7b28]
postgres: test test2 [local] INSERT[0x4e91c2]
postgres: test test2 [local] INSERT(AfterTriggerEndQuery+0x55)[0x4e9545]
postgres: test test2 [local] INSERT[0x582d29]
postgres: test test2 [local] INSERT[0x582ea8]
postgres: test test2 [local] INSERT(PortalRun+0x364)[0x583714]
postgres: test test2 [local] INSERT[0x57f745]
postgres: test test2 [local] INSERT(PostgresMain+0x1110)[0x580b70]
postgres: test test2 [local] INSERT[0x55a3e7]
postgres: test test2 [local] INSERT(PostmasterMain+0x6c1)[0x55afa1]
postgres: test test2 [local] INSERT(main+0x183)[0x51c993]
/lib/libc.so.6(__libc_start_main+0xf4)[0x2b7d14c27374]
postgres: test test2 [local] INSERT[0x43e6c9]
======= Memory map: ========
00400000-00701000 r-xp 00000000 08:19 10261
/usr/bin/postgres
00800000-0080c000 rw-p 00300000 08:19 10261
/usr/bin/postgres
0080c000-009fb000 rw-p 0080c000 00:00 0
[heap]
2b7d1411a000-2b7d14135000 r-xp 00000000 08:19 948791
/lib64/ld-2.5.so
2b7d14135000-2b7d14157000 rw-p 2b7d14135000 00:00 0
2b7d14163000-2b7d141e7000 rw-p 2b7d14163000 00:00 0
2b7d14235000-2b7d14236000 r--p 0001b000 08:19 948791
/lib64/ld-2.5.so
2b7d14236000-2b7d14237000 rw-p 0001c000 08:19 948791
/lib64/ld-2.5.so
2b7d14237000-2b7d1423f000 r-xp 00000000 08:19 571744
/lib64/libpam.so.0.78
2b7d1423f000-2b7d1433e000 ---p 00008000 08:19 571744
/lib64/libpam.so.0.78
2b7d1433e000-2b7d1433f000 rw-p 00007000 08:19 571744
/lib64/libpam.so.0.78
2b7d1433f000-2b7d1437f000 r-xp 00000000 08:19 238686
/usr/lib64/libssl.so.0.9.8
2b7d1437f000-2b7d1447f000 ---p 00040000 08:19 238686
/usr/lib64/libssl.so.0.9.8
2b7d1447f000-2b7d14485000 rw-p 00040000 08:19 238686
/usr/lib64/libssl.so.0.9.8
2b7d14485000-2b7d145d0000 r-xp 00000000 08:19 249759
/usr/lib64/libcrypto.so.0.9.8
2b7d145d0000-2b7d146cf000 ---p 0014b000 08:19 249759
/usr/lib64/libcrypto.so.0.9.8
2b7d146cf000-2b7d146f2000 rw-p 0014a000 08:19 249759
/usr/lib64/libcrypto.so.0.9.8
2b7d146f2000-2b7d146f7000 rw-p 2b7d146f2000 00:00 0
2b7d146f7000-2b7d14778000 r-xp 00000000 08:19 398203
/usr/lib64/libkrb5.so.3.2
2b7d14778000-2b7d14878000 ---p 00081000 08:19 398203
/usr/lib64/libkrb5.so.3.2
2b7d14878000-2b7d1487c000 rw-p 00081000 08:19 398203
/usr/lib64/libkrb5.so.3.2
2b7d1487c000-2b7d14881000 r-xp 00000000 08:19 948786
/lib64/libcrypt-2.5.so
2b7d14881000-2b7d14980000 ---p 00005000 08:19 948786
/lib64/libcrypt-2.5.so
2b7d14980000-2b7d14982000 rw-p 00004000 08:19 948786
/lib64/libcrypt-2.5.so
2b7d14982000-2b7d149b0000 rw-p 2b7d14982000 00:00 0
2b7d149b0000-2b7d149b2000 r-xp 00000000 08:19 948775
/lib64/libdl-2.5.so
2b7d149b2000-2b7d14ab2000 ---p 00002000 08:19 948775
/lib64/libdl-2.5.so
2b7d14ab2000-2b7d14ab4000 rw-p 00002000 08:19 948775
/lib64/libdl-2.5.so
2b7d14ab4000-2b7d14ab5000 rw-p 2b7d14ab4000 00:00 0
2b7d14ab5000-2b7d14b09000 r-xp 00000000 08:19 948796
/lib64/libm-2.5.so
2b7d14b09000-2b7d14c08000 ---p 00054000 08:19 948796
/lib64/libm-2.5.so
2b7d14c08000-2b7d14c0a000 rw-p 00053000 08:19 948796
/lib64/libm-2.5.so
2b7d14c0a000-2b7d14d3c000 r-xp 00000000 08:19 948797
/lib64/libc-2.5.so
2b7d14d3c000-2b7d14e3b000 ---p 00132000 08:19 948797
/lib64/libc-2.5.so
2b7d14e3b000-2b7d14e3e000 r--p 00131000 08:19 948797
/lib64/libc-2.5.so
2b7d14e3e000-2b7d14e40000 rw-p 00134000 08:19 948797
/lib64/libc-2.5.so
2b7d14e40000-2b7d14e45000 rw-p 2b7d14e40000 00:00 0
2b7d14e45000-2b7d14e47000 r-xp 00000000 08:19 571700
/lib64/libcom_err.so.2.1
2b7d14e47000-2b7d14f46000 ---p 00002000 08:19 571700
/lib64/libcom_err.so.2.1
2b7d14f46000-2b7d14f47000 rw-p 00001000 08:19 571700
/lib64/libcom_err.so.2.1
2b7d14f47000-2b7d14f48000 rw-p 2b7d14f47000 00:00 0
2b7d14f48000-2b7d14f6b000 r-xp 00000000 08:19 397952
/usr/lib64/libk5crypto.so.3.0
2b7d14f6b000-2b7d1506a000 ---p 00023000 08:19 397952
/usr/lib64/libk5crypto.so.3.0
2b7d1506a000-2b7d1506c000 rw-p 00022000 08:19 397952
/usr/lib64/libk5crypto.so.3.0
2b7d1506c000-2b7d15073000 r-xp 00000000 08:19 398153
/usr/lib64/libkrb5support.so.0.1
2b7d15073000-2b7d15172000 ---p 00007000 08:19 398153
/usr/lib64/libkrb5support.so.0.1
2b7d15172000-2b7d15173000 rw-p 00006000 08:19 398153
/usr/lib64/libkrb5support.so.0.1
2b7d15173000-2b7d15183000 r-xp 00000000 08:19 948794
/lib64/libresolv-2.5.so
2b7d15183000-2b7d15282000 ---p 00010000 08:19 948794
/lib64/libresolv-2.5.so
2b7d15282000-2b7d15284000 rw-p 0000f000 08:19 948794
/lib64/libresolv-2.5.so
2b7d15284000-2b7d15288000 rw-p 2b7d15284000 00:00 0
2b7d15288000-2b7d1528f000 r-xp 00000000 08:19 948778
/lib64/libnss_compat-2.5.so
2b7d1528f000-2b7d1538e000 ---p 00007000 08:19 948778
/lib64/libnss_compat-2.5.so
2b7d1538e000-2b7d15390000 rw-p 00006000 08:19 948778
/lib64/libnss_compat-2.5.so
2b7d15390000-2b7d153a3000 r-xp 00000000 08:19 948789
/lib64/libnsl-2.5.so
2b7d153a3000-2b7d154a2000 ---p 00013000 08:19 948789
/lib64/libnsl-2.5.so
2b7d154a2000-2b7d154a4000 rw-p 00012000 08:19 948789
/lib64/libnsl-2.5.so
2b7d154a4000-2b7d154a6000 rw-p 2b7d154a4000 00:00 0
2b7d154a6000-2b7d154af000 r-xp 00000000 08:19 948785
/lib64/libnss_nis-2.5.so
2b7d154af000-2b7d155ae000 ---p 00009000 08:19 948785
/lib64/libnss_nis-2.5.so
2b7d155ae000-2b7d155b0000 rw-p 00008000 08:19 948785
/lib64/libnss_nis-2.5.so
2b7d155b0000-2b7d155ba000 r-xp 00000000 08:19 948799
/lib64/libnss_files-2.5.so
2b7d155ba000-2b7d156b9000 ---p 0000a000 08:19 948799
/lib64/libnss_files-2.5.so
2b7d156b9000-2b7d156bb000 rw-p 00009000 08:19 948799
/lib64/libnss_files-2.5.so
2b7d156bb000-2b7d16e0b000 rw-s 00000000 00:08 34897921
/SYSV0052e2c1 (deleted)
2b7d16e0b000-2b7d16e2b000 r-xp 00000000 08:19 49046
/usr/lib64/postgresql/plpgsql.so
2b7d16e2b000-2b7d16f2a000 ---p 00020000 08:19 49046
/usr/lib64/postgresql/plpgsql.so
2b7d16f2a000-2b7d16f2c000 rw-p 0001f000 08:19 49046
/usr/lib64/postgresql/plpgsql.so
2b7d16f2c000-2b7d16f38000 r-xp 00000000 08:19 49050
/usr/lib64/postgresql/plpython.so
2b7d16f38000-2b7d17037000 ---p 0000c000 08:19 49050
/usr/lib64/postgresql/plpython.so
2b7d17037000-2b7d17038000 rw-p 0000b000 08:19 49050
/usr/lib64/postgresql/plpython.so
2b7d17038000-2b7d1712d000 r-xp 00000000 08:19 792544
/usr/lib64/libpython2.4.so.1.0
2b7d1712d000-2b7d1722d000 ---p 000f5000 08:19 792544
/usr/lib64/libpython2.4.so.1.0
2b7d1722d000-2b7d1725b000 rw-p 000f5000 08:19 792544
/usr/lib64/libpython2.4.so.1.0
2b7d1725b000-2b7d17262000 rw-p 2b7d1725b000 00:00 0
2b7d1728f000-2b7d172a4000 r-xp 00000000 08:19 948774
/lib64/libpthread-2.5.so
2b7d172a4000-2b7d173a3000 ---p 00015000 08:19 948774
/lib64/libpthread-2.5.so
2b7d173a3000-2b7d173a4000 r--p 00014000 08:19 948774
/lib64/libpthread-2.5.so
2b7d173a4000-2b7d173a5000 rw-p 00015000 08:19 948774
/lib64/libpthread-2.5.so
2b7d173a5000-2b7d173a9000 rw-p 2b7d173a5000 00:00 0
2b7d173a9000-2b7d173ab000 r-xp 00000000 08:19 948790
/lib64/libutil-2.5.so
2b7d173ab000-2b7d174aa000 ---p 00002000 08:19 948790
/lib64/libutil-2.5.so
2b7d174aa000-2b7d174ac000 rw-p 00001000 08:19 948790
/lib64/libutil-2.5.so
2b7d174ac000-2b7d174ed000 rw-p 2b7d174ac000 00:00 0
2b7d174ee000-2b7d17560000 rw-p 2b7d174ee000 00:00 0
2b7d1758d000-2b7d17599000 r-xp 00000000 08:19 822805
/lib64/libgcc_s.so.1
2b7d17599000-2b7d17699000 ---p 0000c000 08:19 822805
/lib64/libgcc_s.so.1
2b7d17699000-2b7d1769a000 rw-p 0000c000 08:19 822805
/lib64/libgcc_s.so.1
2b7d18000000-2b7d18021000 rw-p 2b7d18000000 00:00 0
2b7d18021000-2b7d1c000000 ---p 2b7d18021000 00:00 0
7fff96978000-7fff96990000 rw-p 7fff96978000 00:00 0
[stack]
---------------------------(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
1 Reply
|
|
|
[BUGS] BUG #3525: Lithuanian characters doesn't work in queries with regular expressions
By Rolandas Rudomanskis at Aug 9, 2007, 11:12 pm UTC
The following bug has been logged online: Bug reference: 3525 Logged by: Rolandas Rudomanskis Email address: rolandasr@gmail.com PostgreSQL version: 8.2.3 Operating system: Debian Etch Description: Lithuanian characters doesn't work in queries with regular expressions Details: The database is set... More...
The following bug has been logged online:
Bug reference: 3525
Logged by: Rolandas Rudomanskis
Email address: [email protected: rola...@gmail.com]
PostgreSQL version: 8.2.3
Operating system: Debian Etch
Description: Lithuanian characters doesn't work in queries with
regular expressions
Details:
The database is set to unicode. Debian locale is utf-8.
All lithuanian characters characters, except ė, ų, namely,
ą, č, ę, į, š, ū, ž in non-case sensitive queries specifying word
beginning, are ignored. SQL example:
select * from table1 where title ~* '\\m" + mytext + "';"
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
1 Reply
|
|
|
[BUGS] BUG #3514: buggy install + no manual support (add)
By Lamia Jackson at Aug 7, 2007, 10:06 pm UTC
The following bug has been logged online: Bug reference: 3514 Logged by: Lamia Jackson Email address: jimbosoak@yahoo.com PostgreSQL version: 8.2.4.1 Operating system: win32 Description: buggy install + no manual support (add) Details: Installation completes w/o exceptions when i check off "initial... More...
The following bug has been logged online:
Bug reference: 3514
Logged by: Lamia Jackson
Email address: [email protected: jimb...@yahoo.com]
PostgreSQL version: 8.2.4.1
Operating system: win32
Description: buggy install + no manual support (add)
Details:
Installation completes w/o exceptions when i check off "initial database"
option during install, no port could be selected and it ends up in selecting
port from previous installation in pre-deleted configuration file (probably
from old install registry entry) .... but still don't want to createdb
(firewall was down, and in all previous cases as well, even it's the same
when it's on)
what's behind this kind of failure, service starts and stops ok, path isn't,
-u/-p switches doesn't help it regularly connects but throws an exception
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [email protected: majo...@postgresql.org] so that your
message can get through to the mailing list cleanly
1 Reply
|
|
|
[BUGS] BUG #3520: insert causing error "invalid memory alloc request size 2147483648"
By Brodie Thiesfield at Aug 7, 2007, 6:32 pm UTC
The following bug has been logged online: Bug reference: 3520 Logged by: Brodie Thiesfield Email address: brofield2@jellycan.com PostgreSQL version: 8.2.4 Operating system: Windows XP SP2 Description: insert causing error "invalid memory alloc request size Details: See SQL script and output at:... More...
The following bug has been logged online:
Bug reference: 3520
Logged by: Brodie Thiesfield
Email address: [email protected: brof...@jellycan.com]
PostgreSQL version: 8.2.4
Operating system: Windows XP SP2
Description: insert causing error "invalid memory alloc request size
2147483648"
Details:
See SQL script and output at:
http://jellycan.com/etc/postgres-bug.zip
STEPS TO REPRODUCE
See attached file postgre-bug.sql
Execute with "psql dbname < postgre.bug"
Note that this testcase has been reduced as much as appears possible.
Changes to the script will cause the error to go away (e.g. reducing the
number of strings, removing the analyse statements). The error will also
disappear if the data is dumped/loaded with pg_dump and the INSERT statement
executed.
OUTPUT
(at time of final INSERT)
ERROR: XX000: invalid memory alloc request size 2147483648
LOCATION: MemoryContextAlloc, mcxt.c:504
See attached file postgre-bug.out
OUTPUT EXPECTED
No error (same SQL works fine in sqlite and MS SQL).
INSTALLATION
>psql --version
psql (PostgreSQL) 8.2.4
Upgrade installation from 8.2.2 using installer, default options.
Error also existed in version 8.2.2
Running on Windows XP SP2 (Japanese)
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [email protected: majo...@postgresql.org] so that your
message can get through to the mailing list cleanly
3 Replies
|
|
|
RE : RE : [BUGS] BUG #3519: Postgres takes the wrong query plan resulting in performance issues
By Mouhamadou DIA at Aug 7, 2007, 2:31 pm UTC
Sorry, This output is coming from PG 8.1.19 I'm attaching the one that is coming from 8.2.4 Thanks and sorry for the confusion -----Message d'origine----- De : Heikki Linnakangas [mailto:hlinnaka@gmail.com] De la part de Heikki Linnakangas Envoyé : 6 août 2007 15:32 À : Mouhamadou Dia Cc :... More...
Sorry,
This output is coming from PG 8.1.19
I'm attaching the one that is coming from 8.2.4
Thanks and sorry for the confusion
-----Message d'origine-----
De : Heikki Linnakangas [email protected: hli...@gmail.com] De la part de Heikki Linnakangas
Envoyé : 6 août 2007 15:32
À : Mouhamadou Dia
Cc : [email protected: pgsql...@postgresql.org]
Objet : Re: RE : [BUGS] BUG #3519: Postgres takes the wrong query plan resulting in performance issues
Mouhamadou Dia wrote:
> I'm sending in attachment the output of the explain analyze command and the create table statements of tables involved in the query.
Wait, you said that the query takes 20 seconds on 8.2, but the explain
analyze output says that it actually took 50 seconds. Is this the output
from 8.2.4?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com ---------------------------(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
Attachment: export_8.2.4.csv6 Replies 
|
|
|
[BUGS] Having trouble building 64-bit pgsql 7.4.17 on HPUX ia64
By Rajaram J at Aug 7, 2007, 2:11 pm UTC
Hi I'm having trouble building 64-bit pgsql 7.4.17 on the latest release of HP-UX 11.23 on ia64. Here's my compiler: cc: HP C/aC++ B3910B A.06.15 [May 16 2007] Here's my error: /opt/ansic/bin/cc -Ae +O2 -L../../src/port -Wl,+nodefaultrpath -L/usr/lib -L/opt/openssl/lib -Wl,+b... More...
Hi
I'm having trouble building 64-bit pgsql 7.4.17 on the latest release of HP-UX 11.23 on ia64.
Here's my compiler:
cc: HP C/aC++ B3910B A.06.15 [May 16 2007]
Here's my error:
/opt/ansic/bin/cc -Ae +O2 -L../../src/port -Wl,+nodefaultrpath -L/usr/lib -L/opt/openssl/lib -Wl,+b -Wl,/opt/rajaram/postgresql/lib -Wl,-z -Wl,-E access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o -lc -lssl -lcrypto -lgen -ldld -lnsl -ldl -lm -lkrb5 -lk5crypto -lcom_err -lpgport -o postgres
ld: Unsatisfied symbol "tas" in file access/SUBSYS.o
1 errors.
gmake[2]: *** [postgres] Error 1
gmake[2]: *** Deleting file `postgres'
gmake[2]: Leaving directory `/postgresql/postgresql-7.4.17/src/backend'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/postgresql/postgresql-7.4.17/src'
gmake: *** [all] Error 2
hpdst156 B.11.23 64_bit >cc v
cc: warning 1913: `v' does not exist or cannot be read
ld: I/O error, file "v": No such file or directory
Fatal error.
Could anyone please advise on how to make 7.4.17 build here?
Regards
Rajaram J
2 Replies
|
|
|
[BUGS] BUG #3521: ExecuteCommandTextForSingleResult : Fatal error in query
By Ravikumar at Aug 7, 2007, 1:28 pm UTC
The following bug has been logged online: Bug reference: 3521 Logged by: Ravikumar Email address: raviit123@rediffmail.com PostgreSQL version: Latest Version Operating system: Win 2003 Description: ExecuteCommandTextForSingleResult : Fatal error in query Details: Hi, I have got this new error while... More...
The following bug has been logged online:
Bug reference: 3521
Logged by: Ravikumar
Email address: [email protected: ravi...@rediffmail.com]
PostgreSQL version: Latest Version
Operating system: Win 2003
Description: ExecuteCommandTextForSingleResult : Fatal error in query
Details:
Hi, I have got this new error while executing my application which is in
vb.net.
ExecuteCommandTextForSingleResult : Fatal error in query
ERROR: relation "t_localisation" does not exist
at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult(tagDBPARAMS
dbParams, Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteCommandText(Object&
executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteCommand(CommandBehavior
behavior, Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior
behavior, String method)
at System.Data.OleDb.OleDbCommand.ExecuteReader(CommandBehavior
behavior)
at
System.Data.OleDb.OleDbCommand.System.Data.IDbCommand.ExecuteReader(CommandB
ehavior behavior)
at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset,
DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String
srcTable, IDbCommand command, CommandBehavior behavior)
at System.Data.Common.DbDataAdapter.Fill(DataTable[] dataTables, Int32
startRecord, Int32 maxRecords, IDbCommand command, CommandBehavior
behavior)
at System.Data.Common.DbDataAdapter.Fill(DataTable dataTable)
at FMM.FMM_SQLTools.QueryToDataTable(String Query, CryptographyLevel
CryptographyLevel) in
D:\Utilisat\LVallee\Project\FMM\FMMGenerator\FMM\Lib\FMM_SQLTools.vb:line
247
LocalConnection:Query=SELECT T_LOCALISATION.ID_LOCALISATION,
T_LOCALISATION.C_LOCALISATION, T_LOCALISATION.L_LOCALISATION,
T_LOCALISATION.BIN_LOCALISATION_IMAGE FROM T_LOCALISATION WHERE
T_LOCALISATION.C_LOCALISATION = 'FR-fre'
dt.Rows.Count=0
at FMM.FMM_SQLTools.QueryToDataTable(String Query, CryptographyLevel
CryptographyLevel) in
D:\Utilisat\LVallee\Project\FMM\FMMGenerator\FMM\Lib\FMM_SQLTools.vb:line
278
at FMM.FMM_Session.QueryToDataTable(String Query, String ConnectionKey)
in D:\Utilisat\LVallee\Project\FMM\FMMGenerator\FMM\Base\FMM_Session.vb:line
6448
at FMM.TLocalisation.GetInstanceByExecSQL(String szSelect, String szFrom,
String szWhere, String[] MembersToTranslate, String
CDictionaryContextTarget, TCountry tCountryTarget, TLanguage
tLanguageTarget, Boolean NoProperty, Boolean NoExtendedProperty) in
D:\Utilisat\LVallee\Project\FMM\FMMGenerator\FMM\Classes\TLocalisation.vb:li
ne 1714
at FMM.TLocalisation.GetLocalisation(Int32 IdLocalisation, String
CLocalisation, String LLocalisation, TLocCompanyLang tLocCompanyLang,
TTranslationMemory tTranslationMemory, Condition Conditions, String[]
MembersToTranslate, String CDictionaryContextTarget, TCountry
tCountryTarget, TLanguage tLanguageTarget, Boolean NoProperty, Boolean
NoExtendedProperty) in
D:\Utilisat\LVallee\Project\FMM\FMMGenerator\FMM\Classes\TLocalisation.vb:li
ne 1668
at FMM.MLocalisation.CreateOrUpdate_Localisation(FMM_Session FMMSession,
String Code, Boolean UseMD5, String LLocalisation) in
D:\Utilisat\LVallee\Project\FMM\FMMGenerator\FMM\Modules\MLocalisation.vb:li
ne 168
at FMM.MLocalisation.InitDatabase(FMM_Session FMMSession) in
D:\Utilisat\LVallee\Project\FMM\FMMGenerator\FMM\Modules\MLocalisation.vb:li
ne 161
at ImportScheduler.ISResources.InitBlankDatabase(FMM_Session FMMSession,
Configuration WebConfigurationFile, AppSettingsReader AppConfigurationFile)
in D:\Users\Rninama\ImportScheduler\App_Code\Common\ISResources.vb:line 290
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
1 Reply
|
|
|
RE : [BUGS] BUG #3519: Postgres takes the wrong query plan resulting in performance issues
By Mouhamadou DIA at Aug 6, 2007, 7:31 pm UTC
I'm sending in attachment the output of the explain analyze command and the create table statements of tables involved in the query. Yes, I have vacuumed and analyzed my database this morning before running the query. I'm sorry; I thought it was a bug with the optimizer, that's why I used the... More...
I'm sending in attachment the output of the explain analyze command and the create table statements of tables involved in the query.
Yes, I have vacuumed and analyzed my database this morning before running the query.
I'm sorry; I thought it was a bug with the optimizer, that's why I used the reporting bug
Thanks for your help
-----Message d'origine-----
De : Heikki Linnakangas [email protected: hli...@gmail.com] De la part de Heikki Linnakangas
Envoyé : 6 août 2007 14:32
À : Mouhamadou Dia
Cc : [email protected: pgsql...@postgresql.org]
Objet : Re: [BUGS] BUG #3519: Postgres takes the wrong query plan resulting in performance issues
Mouhamadou DIA wrote:
> I've migrated to Postgres 8.2.4 and run the same query. It takes now 20
> seconds which is still not acceptable.
To help you with that, we'd need to see the EXPLAIN ANALYZE output of
the query, and the CREATE TABLE statements of the tables involved in the
query and their indexes.
Have you vacuumed and ANALYZEd your database recently?
PS. This is not a bug. Please don't use the bug reporting form for
classic performance issues.
1 Reply
|
|
|
[BUGS] BUG #3519: Postgres takes the wrong query plan resulting in performance issues
By Mouhamadou DIA at Aug 6, 2007, 6:32 pm UTC
The following bug has been logged online: Bug reference: 3519 Logged by: Mouhamadou DIA Email address: mdia@accovia.com PostgreSQL version: 8.2.4 Operating system: Solaris 10 and Linux Redhat 4 Description: Postgres takes the wrong query plan resulting in performance issues Details: Hello, I have a... More...
The following bug has been logged online:
Bug reference: 3519
Logged by: Mouhamadou DIA
Email address: [email protected: m...@accovia.com]
PostgreSQL version: 8.2.4
Operating system: Solaris 10 and Linux Redhat 4
Description: Postgres takes the wrong query plan resulting in
performance issues
Details:
Hello,
I have a Postgres instance (version 8.1.19) running on a Solaris 10 machine.
When I run the following query
SELECT * FROM PROR_ORG, ( ( ( ( (PRPT_PRT LEFT OUTER JOIN PRPT_PRTADR ON
PRPT_PRT.PRT_NRI = PRPT_PRTADR.PRT_NRI AND PRPT_PRTADR.ADR_F_DEF=true)
LEFT OUTER JOIN PLGE_CTY ON PRPT_PRTADR.CTY_NRI = PLGE_CTY.CTY_NRI) LEFT
OUTER JOIN PLGE_CTY1 PLGE_CTY_PLGE_CTY1 ON PLGE_CTY.CTY_NRI =
PLGE_CTY_PLGE_CTY1.CTY_NRI AND PLGE_CTY_PLGE_CTY1.LNG_CD = 'fr') LEFT
OUTER JOIN PLGE_CTRSD ON PRPT_PRTADR.CTRSD_CD = PLGE_CTRSD.CTRSD_CD
AND PRPT_PRTADR.CTR_ISO_CD = PLGE_CTRSD.CTR_ISO_CD) LEFT OUTER JOIN
PLGE_CTR ON PRPT_PRTADR.CTR_ISO_CD = PLGE_CTR.CTR_ISO_CD) , PROR_ORG1
PROR_ORG_PROR_ORG1, PROR_ORGT, PROR_ORGT1 PROR_ORGT_PROR_ORGT1
WHERE ( (PROR_ORG.ORGT_CD = PROR_ORGT.ORGT_CD) AND
(PROR_ORGT.ORGT_CD = PROR_ORGT_PROR_ORGT1.ORGT_CD AND
PROR_ORGT_PROR_ORGT1.LNG_CD = 'fr') AND (PROR_ORG.PRT_NRI =
PROR_ORG_PROR_ORG1.PRT_NRI AND PROR_ORG_PROR_ORG1.LNG_CD = 'fr') AND
(PROR_ORG.PRT_NRI = PRPT_PRT.PRT_NRI) ) AND ( ((PROR_ORG.ORGT_CD ='CHAIN'))
)
it takes 45 seconds to run. In this case the optimizer does a sequential
scan of the PRPT_PRT table (which is the largest one) despite the existence
of an index on PRT_NRI column of PRPT_PRT table.
I’ve activated the GEQO but it still takes nearly the same time to run
(between 40 and 45s).
When I change the order of PRPT_PRT and PROR_ORG tables, it takes only 30
milliseconds to run. In this case the optimizer uses the index on PRT_NRI
column of PRPT_PRT table, what is normal and what I was expecting.
Is there a known problem with the Postgres optimizer?
For your information, the same query takes 20 milliseconds to run on
Informix and 60 milliseconds to run on Oracle independently of the order of
the tables in the query.
PRPT_PRT has 1.3 millions rows
PRPT_PRTADR has 300.000 rows
PROR_ORG has 1500 rows
These are the largest tables, all the others are small tables. All
statistics are up to date.
I read from the release notes that starting from Postgres 8.2 the optimizer
supports reordering outer joins.
I've migrated to Postgres 8.2.4 and run the same query. It takes now 20
seconds which is still not acceptable.
PS: I did the same test using Redhat Linux 4 and I have similar times
Please help
Thanks
1 Reply
|
|
|
[BUGS] BUG #3518: ERROR: IN types character varying and integer cannot be matched
By Tomasz Kawczynski at Aug 6, 2007, 3:17 pm UTC
The following bug has been logged online: Bug reference: 3518 Logged by: Tomasz Kawczynski Email address: sober.pl@gmail.com PostgreSQL version: 8.2.4 Operating system: Linux Gentoo Description: ERROR: IN types character varying and integer cannot be matched Details: Hello everyone, After SELECT *... More...
The following bug has been logged online:
Bug reference: 3518
Logged by: Tomasz Kawczynski
Email address: [email protected: sob...@gmail.com]
PostgreSQL version: 8.2.4
Operating system: Linux Gentoo
Description: ERROR: IN types character varying and integer cannot be
matched
Details:
Hello everyone,
After
SELECT * FROM s_skladnik WHERE kod IN (902,902)
kod character(3)
i get error message
ERROR: IN types character varying and integer cannot be matched
whitch is ok (ive read about this restriction in 8.2.x)
but why after
SELECT * FROM s_skladnik WHERE kod IN (902)
or
SELECT * FROM s_skladnik WHERE kod = 902
I dont get error but query gives me correct result ?
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
1 Reply
|
|
|
[BUGS] BUG #3516: Incomplete #ifdef statement in s_lock.h
By Dirk Tilger at Aug 6, 2007, 3:04 pm UTC
The following bug has been logged online: Bug reference: 3516 Logged by: Dirk Tilger Email address: dirk@miriup.de PostgreSQL version: 8.2.4 Operating system: Linux with Intel compiler on ia64 Description: Incomplete #ifdef statement in s_lock.h Details: I have been compiling postgresql 8.0, 8.1... More...
The following bug has been logged online:
Bug reference: 3516
Logged by: Dirk Tilger
Email address: [email protected: d...@miriup.de]
PostgreSQL version: 8.2.4
Operating system: Linux with Intel compiler on ia64
Description: Incomplete #ifdef statement in s_lock.h
Details:
I have been compiling postgresql 8.0, 8.1 and 8.2.4 with the Intel compiler
in the past successfully. This time something went wrong and although I
can't tell precisely how I triggered it, I have found a fix.
We have an increasingly complex Makefile that compiles our third-party
applications. While playing with the options of the compiler I must have
activated something that triggered the #error on line 809 in file s_lock.h.
I was able to fix the problem by changing line 81 of s_lock.h to:
| #if defined(__GNUC__) || defined(__INTEL_COMPILER) || defined(__ICC)
The icc 9.1.045 manual page says (reformatted):
-----8<-----
__ICC Value on IA-32 -- 910
Value on EM64T -- 910
Value on Itanium Architecture -- NA
Notes -- Assigned value refers to the compiler (e.g., 800 is 8.00).
Supported for legacy reasons. Use __INTEL_COMPILER instead.
-----8<-----
Best regards,
Dirk Tilger
PS: I'm not subscribed to the bugs list, put me in CC for communication.
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
4 Replies
|
|
|
Re: [BUGS] BUG #3269: PSQL does not display error output
By Brandon Craig Rhodes at Aug 5, 2007, 02:27 am UTC
interactive session like yours display no error messages, but psql even lost its ability to echo messages to the command line: $ psql db_that_does_not_exist psql: So I starting adding printf() statements to libpq.so.5 to see what was going on, and, when I added a printf() to fe-protocol3.c,... More...
"Bojan Jovanovic" <pgbojan@bjovanovic.com> writes:
> We just upgraded to 8.2.4, and noticed that psql does not display error
> messages, e.g.:
> ...
> shp_production=# select * from asdfafsdf;
On my system I compiled 8.2.4 as well, and not only would an
interactive session like yours display no error messages, but psql
even lost its ability to echo messages to the command line:
$ psql db_that_does_not_exist
psql:
$
So I starting adding printf() statements to libpq.so.5 to see what was
going on, and, when I added a printf() to fe-protocol3.c, suddenly
libpq regained its ability to produce error messages! Removing my
printf() then had no further effect; it was simply re-compiling
fe-protocol3.c that must have done the trick. I have had no further
problems.
I note that gcc-4.1 was upgraded on my (Debian unstable) system
between my first having compiled PostgreSQL, and the compilation today
that resulted in a working libpq:
version that broke fe-protocol3 -> 4.1.2-12
version that fixed fe-protocol3 -> 4.1.2-14
Anyone who wishes to dive further into the secrets of "The Libpq Who
Would Print No Error Messages" may examine it here:
http://rhodesmill.org/tmp/libpq.so.5
By placing it in the current directory and running psql with
LD_PRELOAD set, you can see the problem for yourself (assuming that
your system has enough libraries in common that this libpq can resolve
its symbols):
$ LD_PRELOAD=$PWD/libpq.so.5 psql
psql:
$
If anyone decompiles it and determines why its machine code is broken
whereas the machine code produced by my gcc today works, I would be
fascinated to know. I wonder whether libpq engages in dangerous and
undefined C behavior that only works if the compiler happens to be in
the mood, or whether this was a bug in gcc-4.1?
I noted, by the way, that the broken and the working libpq on my
system at this moment both link against the same libraries; so it must
be a difference in libpq itself, not anything beneath it.
--
Brandon Craig Rhodes [email protected: br...@rhodesmill.org] http://rhodesmill.org/brandon
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend0 Replies
|
|
|
[BUGS] BUG #3513: buggy install + no manual support (add)
By Lamia Jackson at Aug 4, 2007, 11:15 pm UTC
The following bug has been logged online: Bug reference: 3513 Logged by: Lamia Jackson Email address: jimbosoak@yahoo.com PostgreSQL version: 8.2.4.1 Operating system: win32 Description: buggy install + no manual support (add) Details: These parts of installation didn't install properly: procedural... More...
The following bug has been logged online:
Bug reference: 3513
Logged by: Lamia Jackson
Email address: [email protected: jimb...@yahoo.com]
PostgreSQL version: 8.2.4.1
Operating system: win32
Description: buggy install + no manual support (add)
Details:
These parts of installation didn't install properly: procedural langs,
contrib files, PostGIS
In fact it doesn't have anything with port cause after reinstalling, i
couldn't do that just with modifing installation (just i cant change def
language and codepage), it stay the same ... installed but not activated
whatever it means. What's even worse it seems that evenm i unistalled old
postgres and newlly install it i still have language i don't wan't (even if
i choose different during the installation it stays the same i choose during
THE FIRST) and English_US is in the registry (found thru log) but not in
console when exceptions are thrown.
And when i try to createdb sagfargu i get these message in some other lang
.... these are reconstructed from log "server closed the connection
unexpectedly. This probably means the server terminated abnormally before or
while processing the request." cause in the same way these unproperly
installed parts terminated and write that to the log.
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
0 Replies
|
|
|
Oddities with ANYARRAY
By Jim Nasby at Aug 4, 2007, 5:01 pm UTC
David Fetter and I were just looking at something on IRC... decibel=# select most_common_vals[1] from pg_stats where tablename='pg_depend' and attname='classid'; ERROR: cannot subscript type anyarray because it is not an array decibel=# select most_common_freqs[1] from pg_stats where... More...
David Fetter and I were just looking at something on IRC...
decibel=# select most_common_vals[1] from pg_stats where tablename='pg_depend' and attname='classid';
ERROR: cannot subscript type anyarray because it is not an array
decibel=# select most_common_freqs[1] from pg_stats where tablename='pg_depend' and attname='classid';
most_common_freqs
-------------------
0.566
(1 row)
ISTM you'd want to be able to reference an individual element of an
ANYARRAY... but this gets even more odd...
decibel=# CREATE OR REPLACE FUNCTION array_to_set(anyarray) RETURNS SETOF anyelement LANGUAGE SQL AS $$
SELECT $1[i] from generate_series(array_lower($1, 1), array_upper($1, 1)) i
$$;
CREATE FUNCTION
decibel=# select array_to_set(most_common_vals) from pg_stats where tablename='pg_depend' and attname='classid';
ERROR: argument declared "anyarray" is not an array but type anyarray
I expected that not to work, but the error is somewhat interesting...
I didn't expect the following to work:
decibel=# select array_to_set(most_common_freqs) from pg_stats where tablename='pg_depend' and attname='classid';
array_to_set
--------------
0.566
0.235667
0.126333
0.0343333
0.02
0.0163333
0.000666667
0.000666667
(8 rows)
decibel=#
ISTM you should be able to call an anyarray function with an anyarray,
and that you should be able to reference individual elements of an
anyarray...
--
Decibel!, aka Jim Nasby [email protected: de...@decibel.org]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (FreeBSD)
iD8DBQFGr9sBdO30qud8SkgRAqDmAJ9k+rytIVSU9Udv0VZtH8Ix++aa1gCeJ87j
mfMzD7Jc4wcQgdn3YaOsbts=
=up9e
-----END PGP SIGNATURE-----
6 Replies
|
|
|
BUG #3499: no owner privileges in information_schema.table_privileges
By Kirill Simonov at Aug 4, 2007, 4:53 pm UTC
The following bug has been logged online: Bug reference: 3499 Logged by: Kirill Simonov Email address: xi@gamma.dn.ua PostgreSQL version: 8.2.4 Operating system: Linux Description: no owner privileges in information_schema.table_privileges Details: Owner privileges are not listed in the output of... More...
The following bug has been logged online:
Bug reference: 3499
Logged by: Kirill Simonov
Email address: [email protected: x...@gamma.dn.ua]
PostgreSQL version: 8.2.4
Operating system: Linux
Description: no owner privileges in
information_schema.table_privileges
Details:
Owner privileges are not listed in the output of the
information_schema.table_privileges view when no privileges are granted to
other users. However if at least one GRANT statement was applied to a
table, the table owner appears in the "table_privileges".
The following example illustrates the problem:
-- initialize the test environment: create two users: test_owner and
test_user and create a table test_table, which owner is test_owner.
# create user test_owner;
# create user test_user;
# create table test_table ();
# alter table test_table owner to test_owner;
-- table_privileges contains no rows for 'test_tables'
# select grantee, privilege_type from information_schema.table_privileges
where table_name = 'test_table';
(0 rows)
-- add a privilege for some other user.
# grant select on test_table to test_user;
-- suddenly, not only the test_user privileges appear in "table_privileges",
but the "test_owner" privileges appear as well.
# select grantee, privilege_type from information_schema.table_privileges
where table_name = 'test_table';
grantee | privilege_type
------------+----------------
test_owner | SELECT
test_owner | DELETE
test_owner | INSERT
test_owner | UPDATE
test_owner | REFERENCES
test_owner | TRIGGER
test_user | SELECT
(7 rows)
-- drop test_*.
# drop table test_table;
# drop user test_user;
# drop user test_owner;
1 Reply
|
|
|
[BUGS] BUG #3511: timeofday()::timestamp failing on Saturday when using australian_timezones = on
By Adam at Aug 4, 2007, 3:28 pm UTC
The following bug has been logged online: Bug reference: 3511 Logged by: Adam Email address: adam@subdesigns.net PostgreSQL version: 8.1.9 Operating system: Debian etch, using postgresql-8.1:8.1.9-0etch1 Description: timeofday()::timestamp failing on Saturday when using australian_timezones = on... More...
The following bug has been logged online:
Bug reference: 3511
Logged by: Adam
Email address: [email protected: a...@subdesigns.net]
PostgreSQL version: 8.1.9
Operating system: Debian etch, using postgresql-8.1:8.1.9-0etch1
Description: timeofday()::timestamp failing on Saturday when using
australian_timezones = on
Details:
Conversion to a timestamp is failing to decode a timeofday() date string
which has both 'Sat' and a timezone 'EST', when australian_timezones is
enabled.
date config is set as:
datestyle = 'iso, dmy'
australian_timezones = on
Following code details the conversion issue. Removal of the 'EST' timezone,
or changing to a different (even invalid) day does not result in an error.
erams=# select timeofday();
timeofday
-------------------------------------
Sat Aug 04 12:17:29.290100 2007 EST
(1 row)
erams=# select timeofday()::timestamp;
ERROR: invalid input syntax for type timestamp: "Sat Aug 04 12:17:29.290100
2007 EST"
erams=# select 'Sat Aug 04 12:17:29.290100 2007 EST'::timestamp;
ERROR: invalid input syntax for type timestamp: "Sat Aug 04 12:17:29.290100
2007 EST"
erams=# select 'Sun Aug 05 12:17:29.290100 2007 EST'::timestamp;
timestamp
--------------------------
2007-08-05 12:17:29.2901
(1 row)
erams=# select 'Sat Aug 11 12:17:29.290100 2007 EST'::timestamp;
ERROR: invalid input syntax for type timestamp: "Sat Aug 11 12:17:29.290100
2007 EST"
erams=# select 'Sun Aug 11 12:17:29.290100 2007 EST'::timestamp;
timestamp
--------------------------
2007-08-11 12:17:29.2901
(1 row)
erams=# select 'Sat Aug 10 12:17:29.290100 2007 EST'::timestamp;
ERROR: invalid input syntax for type timestamp: "Sat Aug 10 12:17:29.290100
2007 EST"
erams=# select 'Sat Aug 09 12:17:29.290100 2007 EST'::timestamp;
ERROR: invalid input syntax for type timestamp: "Sat Aug 09 12:17:29.290100
2007 EST"
erams=# select 'Sat Aug 04 12:17:29.290100 2007'::timestamp;
timestamp
--------------------------
2007-08-04 12:17:29.2901
(1 row)
erams=# select 'Mon Aug 04 12:17:29.290100 2007 EST'::timestamp;
timestamp
--------------------------
2007-08-04 12:17:29.2901
(1 row)
Conversion to timestamptz also results in same issue:
erams=# select timeofday()::timestamptz;
ERROR: invalid input syntax for type timestamp with time zone: "Sat Aug 04
12:52:47.381035 2007 EST"
Removal of the 'Sat' corrects the issue:
erams=# select substring(timeofday() from '^[^[:space:]]* (.*
[[:digit:]]{4})')::timestamp;
substring
----------------------------
2007-08-04 13:33:20.825623
(1 row)
erams=# select substring(timeofday() from '^[^[:space:]]* (.*
[[:digit:]]{4})')::timestamp::timestamptz
erams-# ;
substring
-------------------------------
2007-08-04 13:33:26.137588+10
(1 row)
Changing australian_timezones = off corrects the issue.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
1 Reply
|
|
 | |
