[BUGS] BUG #4609: Installer cannot start postgresql service succesfully
The following bug has been logged online: Bug reference: 4609 Logged by: Alex Email address: alex...@hotmail.com PostgreSQL version: 8.2+ Operating system: Windows 7 Description:Installer cannot start postgresql service succesfully Details: Hi, I tried to install versions 8.2 and 8.3 of postgresql db on my machine running Windows 7 Beta 1. All the installation process went fine until the step when it tries to start postgresql service, where it fails saying that I must verify the I have the rights to start system services. After researching in the web and posting the problem into a forum, I found that version 8.0 of postgresql works just fine in Windows 7, so I realized that maybe something is wrong within the installer of versions 8.2 & 8.3 (maybe with other versions after 8.0, I just tested the ones I mentioned). I'm aware that I'm using a Beta version of an OS and there's always issues with certain software, but I think it would be nice if you can take a look at this and look for a solution for future releases. Thanks! -- 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 #4783: new syntax in tablefunction - not output cells
The following bug has been logged online:
Bug reference: 4783
Logged by: Alex
Email address: okto...@mail.ru
PostgreSQL version: 8.4
Operating system: WinXP
Description:new syntax in tablefunction - not output cells
Details:
CREATE TABLE tst (
"id" BIGSERIAL,
"vl" DOUBLE PRECISION DEFAULT 0 NOT NULL,
CONSTRAINT "tst_pkey" PRIMARY KEY("id")
) WITHOUT OIDS;
INSERT INTO tst(id)
VALUES (1),(2),(2),(2),(2),(2),(2),(2),(2),(2),
(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),
(2),(2),(2),(2),(2),
(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),
(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),
(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),
(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2),(2);
CREATE OR REPLACE FUNCTION
test1 () RETURNS TABLE(id BIGINT, vl DOUBLE PRECISION) AS
$body$
BEGIN
RETURN QUERY
SELECT
id,
vl
FROM tst;
END
$body$
LANGUAGE 'plpgsql'
IMMUTABLE
CALLED ON NULL INPUT
SECURITY DEFINER
COST 1000 ROWS 1000;
CREATE OR REPLACE FUNCTION
test2 () RETURNS TABLE(id BIGINT, vl DOUBLE PRECISION) AS
$body$
SELECT
id,
vl
FROM tst;
END
$body$
LANGUAGE 'sql'
IMMUTABLE
CALLED ON NULL INPUT
SECURITY DEFINER
COST 1000 ROWS 1000;
query SELECT * FROM test1(); return NULL's if
name columns in "RETURN QUERY" = name columns in
"RETURNS TABLE".
was tested with languages: plpgsql and sql
this is bag or feature?
thank's
--
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 #4798: BitMapAnd never works with gin
The following bug has been logged online:
Bug reference: 4798
Logged by: Alex
Email address: a...@xdcom.org
PostgreSQL version: 8.3.6
Operating system: rhel5
Description:BitMapAnd never works with gin
Details:
CREATE TABLE foo
(
id serial NOT NULL,
name character varying(32),
nick character varying(32),
gender integer
)WITH (OIDS=FALSE);
CREATE INDEX name_idx
ON foo
USING gin(to_tsvector('english'::regconfig, name))
WHERE gender = 1;
CREATE INDEX nick_idx
ON foo
USING gin(to_tsvector('english'::regconfig, nick))
WHERE gender = 1;
-
"select count(0) from foo where gender"
-
100,000.
"select relname,relpages,relkind,reltuples from pg_class where relname ~
'name_idx';"
-
name_idx | 280 | i |10
"SELECT count(id) FROM foo where gender = 1 and
"to_tsvector('english',name) @@ 'alex'"
-
4000
"SELECT count(id) FROM foo where gender = 1 and
"to_tsvector('english',nick) @@ 'ali'"
-----
3000
"EXPLAIN SELECT id FROM foo where gender = 1 and
to_tsvector('english',name) @@ 'alex' and to_tsvector('english',nick) @@
'ali';"
-
Bitmap Heap Scan on foo (cost=4.37..63.85 rows=1 width=4)
Recheck Cond: ((to_tsvector('english'::regconfig, (name)::text) @@
'''alex'''::tsquery) AND (gender = 1))
Filter: (to_tsvector('english'::regconfig, (nick)::text) @@
'''ali'''::tsquery)
-> Bitmap Index Scan on name_idx (cost=0.00..4.37 rows=15 width=0)
Index Cond: (to_tsvector('english'::regconfig, (name)::text) @@
'''alex'''::tsquery)
The actual cost is exhausting.
I think the gepo should give BitMapAnd better.
--
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 #4799: BitMapAnd never works with gin
The following bug has been logged online:
Bug reference: 4799
Logged by: Alex
Email address: a...@xdcom.org
PostgreSQL version: 8.3.6
Operating system: rhel5
Description:BitMapAnd never works with gin
Details:
CREATE TABLE foo
(
id serial NOT NULL,
name character varying(32),
nick character varying(32),
gender integer
)WITH (OIDS=FALSE);
CREATE INDEX name_idx
ON foo
USING gin(to_tsvector('english'::regconfig, name))
WHERE gender = 1;
CREATE INDEX nick_idx
ON foo
USING gin(to_tsvector('english'::regconfig, nick))
WHERE gender = 1;
-
"select count(0) from foo where gender=1;"
-
100,000.
"select relname,relpages,relkind,reltuples from pg_class where relname ~
'name_idx';"
-
name_idx | 280 | i |10
"SELECT count(id) FROM foo where gender = 1 and to_tsvector('english',name)
@@ 'alex'"
-
4000
"SELECT count(id) FROM foo where gender = 1 and
to_tsvector('english',nick) @@ 'ali'"
-
3000
"EXPLAIN SELECT id FROM foo where gender = 1 and
to_tsvector('english',name) @@ 'alex' and to_tsvector('english',nick) @@
'ali';"
-----
Bitmap Heap Scan on foo (cost=4.37..63.85 rows=1 width=4)
Recheck Cond: ((to_tsvector('english'::regconfig, (name)::text) @@
'''alex'''::tsquery) AND (gender = 1))
Filter: (to_tsvector('english'::regconfig, (nick)::text) @@
'''ali'''::tsquery)
-> Bitmap Index Scan on name_idx (cost=0.00..4.37 rows=15 width=0)
Index Cond: (to_tsvector('english'::regconfig, (name)::text) @@
'''alex'''::tsquery)
The actual cost is exhausting.
I think the gepo should give BitMapAnd better.
--
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 #4800: constraint_exclusion could be smarter with bool conversion
The following bug has been logged online: Bug reference: 4800 Logged by: Alex Email address: a...@xdcom.org PostgreSQL version: 8.3.6 Operating system: rhel5 Description:constraint_exclusion could be smarter with bool conversion Details: Table "public.foo1" Column | Type | Modifiers -++ val | character varying(16) | not null mask| integer| default 0 Check constraints: "foo_1_mask_check" CHECK (mask = 1) Inherits: foo => EXPLAIN select * from foo1 where mask >1; QUERY PLAN -- Result (cost=0.00..0.01 rows=1 width=0) One-Time Filter: false (2 rows) => EXPLAIN select * from foo1 where (mask &2)::bool; QUERY PLAN - Seq Scan on foo1 (cost=0.00..100.32 rows=896 width=59) Filter: ((mask & 2))::boolean (2 rows) There many children of table foo like foo1,..fooN. with different check(mask=2^N). I wish constraint_exclusion to be smarter with bool conversion so that 'select * from foo where (mask&5)::bool' can be faster; -- 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 #4828: Fault a foreign key
The following bug has been logged online: Bug reference: 4828 Logged by: alex Email address: alexafanas...@yandex.ru PostgreSQL version: PostgreSQL8.3.7 Operating system: Windows XP 2002 SP2 Description:Fault a foreign key Details: Run in psql: --DROP DATABASE test_fk; CREATE DATABASE test_fk WITH TEMPLATE = template0; ALTER DATABASE test_fk OWNER TO postgres; \connect test_fk CREATE PROCEDURAL LANGUAGE plpgsql; ALTER PROCEDURAL LANGUAGE plpgsql OWNER TO postgres; SET search_path = public, pg_catalog; CREATE TABLE tbl11 ( id_tbl1 serial NOT NULL, cl1 integer NOT NULL, naim text ); CREATE TABLE tbl12 ( id_tbl2 serial NOT NULL, cl1 integer NOT NULL, kod character(1) ); ALTER TABLE public.tbl12 OWNER TO postgres; CREATE FUNCTION tr_f1() RETURNS trigger AS $$ BEGIN IF NEW.kod = 'a' THEN NEW.cl1 = OLD.cl1; END IF; RETURN NEW; END; $$ LANGUAGE plpgsql; CREATE FUNCTION tr_f2() RETURNS trigger AS $$ BEGIN IF OLD.kod = 'c' THEN RETURN NULL; END IF; RETURN OLD; END; $$ LANGUAGE plpgsql; -- INSERT INTO tbl11(cl1, naim) VALUES ( 1, '1/1'); INSERT INTO tbl11(cl1, naim) VALUES ( 2, '1/2'); INSERT INTO tbl12( cl1, kod)VALUES ( 1, 'a'); INSERT INTO tbl12( cl1, kod) VALUES ( 1, 'b'); INSERT INTO tbl12( cl1, kod)VALUES ( 2, 'c'); INSERT INTO tbl12( cl1, kod)VALUES ( 2, 'd'); ALTER TABLE ONLY tbl11 ADD CONSTRAINT sui UNIQUE (cl1); CREATE TRIGGER tr1 BEFORE UPDATE ON tbl12 FOR EACH ROW EXECUTE PROCEDURE tr_f1(); CREATE TRIGGER tr2 BEFORE DELETE ON tbl12 FOR EACH ROW EXECUTE PROCEDURE tr_f2(); ALTER TABLE ONLY tbl12 ADD CONSTRAINT fk FOREIGN KEY (cl1) REFERENCES tbl11(cl1) ON UPDATE CASCADE ON DELETE CASCADE; Run in psql: UPDATE tbl11 SET cl1=5 WHERE cl1=1; DELETE FROM tbl11 WHERE cl1=2; SELECT * FROM tbl12 WHERE not exists(select 1 from tbl11 WHERE tbl11.cl1 = tbl12.cl1); -- 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 #5362: WARNING could not determine encoding
The following bug has been logged online: Bug reference: 5362 Logged by: ALEX Email address: bav...@mail.ru PostgreSQL version: 8.3 Operating system: linux ubuntu 9.10 server Description:WARNING could not determine encoding Details: # sudo pg_createcluster -e koi8 --locale=uk_UA.koi8u --lc-ctype=uk_UA.koi8u --lc-collate=uk_UA.koi8u -d /mnt/test 8.3 test Creating new cluster (configuration: /etc/postgresql/8.3/test, data: /mnt/test)... could not determine encoding for locale "uk_UA.koi8u": codeset is "KOI8-U" WARNING: could not determine encoding for locale "uk_UA.koi8u": codeset is "KOI8-U" DETAIL: Please report this to . WARNING: could not determine encoding for locale "uk_UA.koi8u": codeset is "KOI8-U" DETAIL: Please report this to . -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] timestamp being timestamp with time zone
POSTGRESQL BUG REPORT TEMPLATE Your name : Alex Verstraeten Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel Pentium III Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.19 ELF PostgreSQL version (example: PostgreSQL-7.1.1): PostgreSQL-7.1.1 Compiler used (example: gcc 2.95.2) : gcc version 2.95.2 2220 (Debian GNU/Linux) Please enter a FULL description of your problem: When creating a table with a timestamp date type, timestamp becomes timestamp with time zone. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- in psql: CREATE TABLE "foo" ( bar timestamp ); \d foo Table "foo" Attribute | Type | Modifier ---+--+-- bar | timestamp with time zone | another sample: CREATE TABLE "bar" ( foo timestamp without time zone ); \d bar Table "bar" Attribute | Type | Modifier ---+--+-- foo | timestamp with time zone | by reading the current docs (http://postgresql.readysetnet.com/devel-corner/docs/postgres/datatype-datet ime.html) I can tell timestamp and timestamp with time zone are two different date/time types. If you know how this problem might be fixed, list the solution below: - I'm afraid not. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] BUG #3467: Sum strange behaviour
The following bug has been logged online: Bug reference: 3467 Logged by: Alex Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: FreeBSD 6.2-RELEASE-p4 Description:Sum strange behaviour Details: I have a database with some float numbers (all of them are 2 digits presision). When I do select sum() I get this: 96.31001 Here are the numbers: 4.29 4.29 0.29 14.3 1.43 14.3 1.43 1.43 7.15 2.94 0.14 5.56 1.43 0.29 0.59 1.43 1.43 1.43 1.43 21.45 1.43 0.14 2.15 1.43 1.43 1.43 1.43 0.59 0.22 1.43 1.18 Is this bug or future ? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] Missing pg_clog file / corrupt index / invalid page header
My colleague Marc Schablewski reported this Bug (#3484) the first time at the end of July. The described problem occured twice at our database and now it happened again. Summary == Various errors like: "invalid page header in block 8658 of relation", "could not open segment 2 of relation 1663/77142409/266753945 (target block 809775152)", "ERROR: could not access status of transaction 2134240 DETAIL: could not open file "pg_clog/0002": File not found", "CEST PANIC: right sibling's left-link doesn't match" on the following system: Postgres 8.1.8 SUsE Linux Kernel 2.6.13-15.8-smp 2 Intel XEON Processors with 2 cores each ECC-Ram Hardware Raid (mirror set) Detailed description === The message was thrown by the nightly pg_dump: pg_dump: ERROR: invalid page header in block 8658 of relation "import_data_zeilen" pg_dump: SQL command to dump the contents of table "import_data_zeilen" failed: PQendcopy() failed. pg_dump: Error message from server: ERROR: invalid page header in block 8658 of relation "import_data_zeilen" pg_dump: The command was: COPY public.import_data_zeilen (id, eda_id, zeile, man_id, sta_id) TO stdout; A manually executed dedicated dump on the concerned table was processed successfully ( at daytime! ) We were really suprised! Also, select-queries (using indexes) on the table succeeded. (in the past when the error occured, select-queries failed). So, no repair seemed to be needed for the table. The following night, the pg_dump succeeded, but the "vacuum analyze" (executed after the pg_dump) threw the same error: INFO: vacuuming "public.import_data_zeilen" ERROR: invalid page header in block 8658 of relation "import_data_zeilen" Any select on this table using indexes now failed! ( if the resultset contained the corrupted data ) This behaviour is very confusing. Re-creating the table solved the problem. However, the damaged rows were lost. We have two systems, one active, one for tests. They are nearly identical, having similar hardare, using the same software and they are running under the same load. The errors always occured on the active server, the test-server didn't run into errors after upgrading both servers from 8.1.3 to 8.1.8. So even though no hardware errors were detected (neither ECC-RAM-Errors nor disk errors) we decided to swap the server's roles, to find out if its a hardware or software problem. This was 12 days ago. Now we got another error, again on the active system (which now uses the hardware from the other system except for the one of the hard disks in the raid), which was thrown by an insert statement done by the software: org.postgresql.util.PSQLException: ERROR: could not open segment 2 of relation 1663/77142409/266753945 (target block 809775152): Datei oder Verzeichnis nicht gefunden. Obviously we have a problem with the he active server. But its unlikely to be a hardware problem, because we changed the hard disks and the error occured at the same (software) system. Also we are using ECC-Ram and a raid system (mirrorset) with hardware raid controller, which hasn't reported any errors. We read the last post/thread concerning this bug. In this thread the problem was connected to some kernel bug in 2.6.11. We are using a higher Linux version: 2.6.13-15.8-smp. Hardware system: 2 dual core processor ( Intel(R) Xeon(TM) CPU 2.80GHz ) postgres-Version: 8.1.8 We have done a lot of database maintenance 4 days ago, which among other updates dropped about 10 indexes on one big table ( 35'000'000 recordsets ) and created some other 10 indexes (for better performance). Given that the problem occurred on two different machines we are very sure that it is *not* a hardware problem. We would really appreciate any help with our problems. Thanks in advance A. Nitzschke ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] Bug (#3484) - Invalid page header again
Hi folks, we had reported about various database problems some weeks ago. Since then we have updated the database to release 8.2.4 und the linux kernel to 2.6.22.6-smp. Now we got an error again: IN SHORT: - data is inserted - the same data is read and exported successfully - after a nightly vacuum analyze the data is corrupted and cannot be read any more. Error message(s): see below CONCLUSION Apparently the data is corrupted by "vacuum analyze". IN DETAIL: We got an error during the nightly dump again: pg_dump: SQL command failed pg_dump: Error message from server: ERROR: invalid memory alloc request size 18446744073709551610 Some records in table "transaktion" (which contains about 45 million records) are corrupted. But the data has not been corrupted after insertion, it must have been corrupted later. Let us explain the track of the error: 1. 2007/12/07 ~3:30h: The (now corrupted) data was inserted successfully 2. 2007/12/07 7h : The (now corrupted) data was read and exported successfully! ( We run an export of the data every morning at 7h, which exports the data we retrieved/inserted during the last 24 hours ) 3. 2007/12/07 22h: Database was dumped successfully 4. 2007/12/07 23:15h: Database "vacuum analyze" was run successfully 5. 2007/12/08 22h: The database dump got the error described above: pg_dump: SQL command failed pg_dump: Error message from server: ERROR: invalid memory alloc request size 18446744073709551610 6. 2007/12/08 23h: "vacuum analyze" threw an error: INFO: vacuuming "public.transaktion" WARNING: relation "transaktion" TID 1240631/12: OID is invalid ERROR: invalid page header in block 1240632 of relation "transaktion" 7. 2007/12/10 : We started the export of the data ( which runs every morning ) for the last days again. These exports use the same SQL-Commands as the automatical run. But now, we got an error when exporting the data for 2007/12/07. ERROR: invalid memory alloc request size 18446744073709551610 The process exporting the same set of data ran successfully in the morning of the 2007/12/07: We are very sure, that the data has not been manipulated since the time of insertion, because the error occurs on the testing system and at the moment no tests except from inserting and exporting the data are done. 8. 2007/12/14 When we now start a select over the corrupted data, we get the error message: ERROR: could not access status of transaction 313765632 DETAIL: Could not open file "pg_clog/012B": Datei oder Verzeichnis nicht gefunden. We are using Linux version: 2.6.22.6-smp. Hardware system: 2 dual core processor ( Intel(R) Xeon(TM) CPU 2.80GHz ) postgres-Version: 8.2.4 Original-Nachricht Betreff: Missing pg_clog file / corrupt index / invalid page header Datum: Wed, 05 Sep 2007 08:18:31 +0200 Von: alex <[EMAIL PROTECTED]> Organisation: click:ware GmbH An: pgsql-bugs@postgresql.org My colleague Marc Schablewski reported this Bug (#3484) the first time at the end of July. The described problem occured twice at our database and now it happened again. Summary == Various errors like: "invalid page header in block 8658 of relation", "could not open segment 2 of relation 1663/77142409/266753945 (target block 809775152)", "ERROR: could not access status of transaction 2134240 DETAIL: could not open file "pg_clog/0002": File not found", "CEST PANIC: right sibling's left-link doesn't match" on the following system: Postgres 8.1.8 SUsE Linux Kernel 2.6.13-15.8-smp 2 Intel XEON Processors with 2 cores each ECC-Ram Hardware Raid (mirror set) Detailed description === The message was thrown by the nightly pg_dump: pg_dump: ERROR: invalid page header in block 8658 of relation "import_data_zeilen" pg_dump: SQL command to dump the contents of table "import_data_zeilen" failed: PQendcopy() failed. pg_dump: Error message from server: ERROR: invalid page header in block 8658 of relation "import_data_zeilen" pg_dump: The command was: COPY public.import_data_zeilen (id, eda_id, zeile, man_id, sta_id) TO stdout; A manually executed dedicated dump on the concerned table was processed successfully ( at daytime! ) We were really suprised! Also, select-queries (using indexes) on the table succeeded. (in the past when the error occured, select-queries failed). So, no repair seemed to be needed for the table. The following night, the pg_dump succeeded, but the "vacuum analyze" (executed after the pg_dump) threw the same error: INFO: vacuuming "public.import_data_zeilen" ERROR: invalid page header in block 8658 of relation "import_data_zeilen" Any select on this table using indexes now failed! ( if the resultset contained the corrupted data ) This behaviour is very confusing. Re-creating the table solved the
[BUGS] BUG #4104: Uninstall/remove not working correctly
The following bug has been logged online: Bug reference: 4104 Logged by: alex Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: windows XP Description:Uninstall/remove not working correctly Details: I recently uninstalled 8.3.1 and I deleted the remaining files not removed from the uninstaller. I then proceed to install 8.3.1 again using same user info as before. The installer proceeded to install until the creation of the user and it says "user postgres already exists" and then rollbacked the install. If I install using different username like postgres1 then everything's fine. Maybe this is not a bug but there is a file i am suppose to remove but missed? -- 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 #4151: Can't connect/start database after restart
The following bug has been logged online: Bug reference: 4151 Logged by: alex Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: windows XP Description:Can't connect/start database after restart Details: Hi, I have 8.3.1 postgres installed and am facing a very weird problem. I install the program fine and it works fine. However, once I restart the computer and try to start the database via command line or pgAdmin3 it gives me error that i can't connect. It tells me to check the logs but i didn't find any error besides the connect error message itself. I then have to uninstall and reinstall all over again... I also have trouble clearing "hidden" history on previous postgres installations - I cleared up the "my documents" folders with previous postgres installations but the computer still warns me whenever i use a previous name. Thanks, Alex -- 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 #4172: postgres stops working after restart
The following bug has been logged online: Bug reference: 4172 Logged by: alex Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: windows xp Description:postgres stops working after restart Details: I installed 8.3.1 fine and the service starts and works fine. However, after I restart the computer and opens up pgAdmin3.exe and try to start the service again i get error message: "Failed to start server pgsql-8.3:Errcode=1069. Check event log for details." The log folder doesn't show any error problems. When I run the psql.exe on the command line i get: "psql: could not connect to server: Connection refused (0x274D/10061) Is the server running on host "???" and accepting TCP/IP connections on port 5432? " I checked using netstat -an and 5432 is not even listed being in use/listening. I also tried changing the port in pgadmin to something else like 5050 but same error. Right now the only "fix" i can come up with is to uninstall and reinstall... is there a fix to this problem? thanks! -- 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 #5950: backend terminating after altering table
The following bug has been logged online: Bug reference: 5950 Logged by: alex Email address: perepelica.a...@gmail.com PostgreSQL version: 9.0.3 Operating system: archlinux x86_64 Description:backend terminating after altering table Details: Such steps: 1. create table t ( ); 2. alter table t add childs t; 3. alter table t add id serial not null primary key; This messages from psql: NOTICE: ALTER TABLE will create implicit sequence "t_id_seq" for serial column "t.id" NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "t_pkey" for table "t" server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. backend - terminated -- 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 #6010: booting problem
The following bug has been logged online: Bug reference: 6010 Logged by: alex Email address: alexandr.kas...@gmail.com PostgreSQL version: 9.1 beta1 Operating system: snow leopard Description:booting problem Details: after changing sysctl.conf values and rebooting (i ve used values in readme file), my permissions changed and now i cant get into my ~/Library folder and all my settings for applications, my mail, other things which is saved in this folder - gone (not accessible)! when i rebooted again, nothing new happened. it is very frustrating that your simple installation steps can be so dangerous. what do i have to do now? fuck. -- 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 #6054: Insert to table, which has fkey to table,which is parenttable for another table - error
The following bug has been logged online: Bug reference: 6054 Logged by: Alex Email address: alexander.ochkal...@gmail.com PostgreSQL version: 8.4.8 Operating system: CentOS Description:Insert to table, which has fkey to table,which is parenttable for another table - error Details: CREATE TABLE t1 (t1_id numeric(10,0) NOT NULL PRIMARY KEY); CREATE TABLE t2 (t2_id numeric(10,0) NOT NULL PRIMARY KEY) INHERITS (t1); CREATE TABLE t3 (t3_id numeric(10,0) NOT NULL PRIMARY KEY , t1_id numeric(10,0) NOT NULL REFERENCES t1(t1_id)) ; INSERT INTO t2 VALUES(1,2); INSERT INTO t3 VALUES(3,1); ERROR: insert or update on table "t3" violates --- foreign key constraint "t3_t1_id_fkey" DETAIL: Key (t1_id)=(1) is not present in table "t1". BUT SELECT t1_id FROM t1 WHERE t1_id = 1; -->1 -- 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 #6159: Can't create unlogged table
The following bug has been logged online: Bug reference: 6159 Logged by: Alex Email address: perepelica.a...@gmail.com PostgreSQL version: 9.1beta3 Operating system: linux x86_64 archlinux Description:Can't create unlogged table Details: Execute from pgadmin create unlogged table public.test ( id serial primary key, some_text text ); And get such error ERROR: only temporary relations may be created in temporary schemas -- 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 #8354: stripped positions can generate nonzero rank in ts_rank_cd
The following bug has been logged on the website:
Bug reference: 8354
Logged by: Alex Hill
Email address: a...@hill.net.au
PostgreSQL version: 9.2.4
Operating system: OS X 10.8.4 Mountain Lion
Description:
Hi all,
The docs for ts_rank_cd state:
"This function requires positional information in its input. Therefore it
will not work on "stripped" tsvector values — it will always return zero."
However if a tsvector contains some stripped lexemes and some non-stripped,
ts_rank_cd will rank extents including the non-stripped values.
For example, this evaluates to zero as expected:
SELECT ts_rank_cd(strip(to_tsvector('text search')),
plainto_tsquery('text search'))
But this doesn't:
SELECT ts_rank_cd(to_tsvector('text') || strip(to_tsvector('search')),
plainto_tsquery('text search'))
I think this is a bug, if not in the code then in the documentation, which
isn't clear on what happens when stripped and positioned lexemes are mixed
in one tsvector.
I would prefer that stripped lexemes were completely ignored by ts_rank_cd:
my use case is using this as a fifth pseudo-weight, which matches a @@ query
but doesn't add to a ts_rank_cd ranking.
What do you think?
Cheers,
Alex
--
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 #4278: pg_dump data outputs when run from command prompt in unreliable
The following bug has been logged online: Bug reference: 4278 Logged by: Alex Balan Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.3 Windows Operating system: Windows XP SP2 Description:pg_dump data outputs when run from command prompt in unreliable Details: Have reinstalled Postgres 8.3.3 on Windows database encoding SQL_ASCII (dbname is remoteupload) have following table: CREATE TABLE scan_d ( scan_idbigint NOT NULL DEFAULT 0, scan_page integer NOT NULL DEFAULT 0, scan_type character(6) NOT NULL DEFAULT ''::bpchar, scan_data bytea, CONSTRAINT pk_scan_id_and_page PRIMARY KEY (scan_id, scan_page) ) WITH OIDS; ALTER TABLE scan_d OWNER TO postgres; GRANT ALL ON TABLE scan_d TO postgres; INSERT INTO scan_d (scan_id,scan_page,scan_type) VALUES (1,1,'TIFF'); INSERT INTO scan_d (scan_id,scan_page,scan_type) VALUES (2,11,'ABC'); INSERT INTO scan_d (scan_id,scan_page,scan_type) VALUES (3,111,'XYZ'); runas /user:CARA2\postgres cmd.exe C:\Program Files\PostgreSQL\8.3\bin\pg_dump.exe -i -h 192.168.100.77 -p 5432 -U postgres -F c -v -D -f "D:\SCAN_DIRBACKUP_DIR\scan_d_upload_20080703175038.backup" -t scan_d -n public remoteupload DELETE FROM scan_d; Now take the backup and restore it in pg_Admin III (ver 1.6.3 rev 6112) SELECT scan_id,scan_page,scan_type FROM scan_d; 60716 1 TIFF It always returns ONLY ONE RECORD with 60716 as scan_id Tried without option -D, same results only one record with id 60716 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4434: Error inserting into view - unrecognized node type: 313
On Tue, Sep 23, 2008 at 10:38 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Dean Rasheed" <[EMAIL PROTECTED]> writes: >> CREATE TABLE foo(a int, b int); >> CREATE VIEW foo_v AS SELECT * FROM foo; >> CREATE RULE foo_r AS ON INSERT TO foo_v DO INSTEAD INSERT INTO foo >> VALUES(NEW.a, NEW.b); >> INSERT INTO foo_v VALUES ((SELECT 1), (SELECT 2)), ((SELECT 3), (SELECT 4)); > >> ERROR: unrecognized node type: 313 > > It looks like the parser's code path for multi-row VALUES is neglecting > to detect sublinks and set pstate->p_hasSubLinks. I'm too tired to look > closer tonight; anyone want to poke into it? > >regards, tom lane The below fixes it for me... Its probably in the wrong place, and does not even try to do any detection... but here it is anyway *** a/src/backend/parser/analyze.c --- b/src/backend/parser/analyze.c *** *** 538,543 transformInsertStmt(ParseState *pstate, InsertStmt *stmt) --- 538,545 */ List *valuesLists = selectStmt->valuesLists; + pstate->p_hasSubLinks = true; + Assert(list_length(valuesLists) == 1); /* Do basic expression transformation (same as a ROW() expr) */ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Incorrect "invalid AM/PM string" error from to_timestamp
On Thu, Sep 25, 2008 at 10:22 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > A likely bet is that this is caused by use of uninitialized memory, > which happens to have garbage rather than zeroes in it the second > time through. Yep both DCH_MC and DCH_US were going past the end of the string because they still added the length of the string where from_char_parse_int_len takes care of that for us now... The attach patch fixes it and tries to improve the "invalid AM/PM string" a bit by showing the string. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Incorrect "invalid AM/PM string" error from to_timestamp
On Thu, Sep 25, 2008 at 4:05 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote: > On Thu, Sep 25, 2008 at 10:22 AM, Tom Lane <[EMAIL PROTECTED]> wrote: >> A likely bet is that this is caused by use of uninitialized memory, >> which happens to have garbage rather than zeroes in it the second >> time through. > > Yep both DCH_MC and DCH_US were going past the end of the string > because they still added the length of the string where > from_char_parse_int_len takes care of that for us now... > > The attach patch fixes it and tries to improve the "invalid AM/PM > string" a bit by showing the string. [Actually attaches the patch...] fix_to_timestamp.patch Description: Binary data -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Tue, Nov 4, 2008 at 09:02, Jeff <[EMAIL PROTECTED]> wrote:
> I've ran into this interesting problem.
> It seems that while you can call sort() in a trusted plperl func you cannot
> access $a & $b which effectively makes it useless.
Hrm works for me if I take out the elog from sort()
create or replace function trustedsort()
returns int
as $$
my @arr = qw(5 4 3 2 1);
my @sorted = sort { $a <=> $b } @arr;
elog(NOTICE, join(' ', @sorted));
return 1;
$$
language 'plperl';
SELECT trustedsort();
NOTICE: 1 2 3 4 5
trustedsort
-
1
(1 row)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Tue, Nov 4, 2008 at 12:39, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>> Hrm works for me if I take out the elog from sort()
>
> Even more interesting, this variant *doesn't* work:
>
> regression=# create or replace function trustedsort()
> returns int
> as $$
> my @arr = qw(5 4 3 2 1);
> my @sorted = sort { "$a" <=> "$b" } @arr;
> elog(NOTICE, join(' ', @sorted));
> return 1;
> $$
> language 'plperl';
> CREATE FUNCTION
> regression=# select trustedsort();
> NOTICE: 5 4 3 2 1
> trustedsort
> -
> 1
> (1 row)
>
> Seems like it's the interpolation into a string that is failing.
It has something to do with anon subs not sure what...
see below test case
This works:
require Safe;
my $safe = Safe->new('PLPerl');
$safe->permit_only(':default');
$safe->permit(qw(sort));
$safe->share(qw(&j));
sub j
{
print "j called ". (shift) . "\n";
}
my $f = $safe->reval(<<'z');
sub blah {
my @c = sort { j("$a $b"); $a <=> $b } qw(5 4 3 2 1);
j(join(" ", @c));
return;
}
blah();
z
$ perl tsafe.pl
j called 5 4
j called 3 2
j called 4 2
j called 4 3
j called 2 1
j called 1 2 3 4 5
This fails: (which is what we do in plperl.c)
my $f = $safe->reval(<<'z');
sub {
my @c = sort { j("$a $b"); $a <=> $b } qw(5 4 3 2 1);
j(join(" ", @c));
return;
}
z
$f->();
$ perl tsafe.pl
j called
j called
j called
j called
j called
j called
j called
j called
j called 5 4 3 2 1
This works:
$safe->reval(<<'z');
my @c = sort { j("$a $b"); $a <=> $b } qw(5 4 3 2 1);
j(join(" ", @c));
return;
z
$ perl tsafe.pl
j called 5 4
j called 3 2
j called 4 2
j called 4 3
j called 2 1
j called 1 2 3 4 5
Dunno...
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Tue, Nov 4, 2008 at 12:43, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> It has something to do with anon subs not sure what...
It has to do with us returning the anonymous sub inside of the safe
and then calling the function outside of the safe (or at least in a
different namespace)
we do something eqvilient to this:
my $func_ptr = $safe->reval('sub { ... }');
$func_ptr->();
because safe makes its own namespace from perldoc Safe
The "root" of the namespace (i.e. "main::") is changed to a
different package and code evaluated in the compartment cannot
refer to variables outside this namespace, even with run-time
glob lookups and other tricks.
I only see one way to "fix" this which is to do something groddy like
share a global variable between the safe and the real interpreter.
Something like:
my $_pl_sub;
sub call_pl_sub
{
retrun $_pl_sub;
}
$safe->share(qw(call_pl_sub);
my $sub = $safe->reval('sub { ...}');
$_pl_sub = $sub;
$safe->reval('call_pl_sub();');
Note I tried just sharing $_pl_sub and doing
$safe->reval('$_pl_sub->()'); but I just get 'Undefined subroutine
&main::'
Should I work up a patch? Assuming someone confirm this?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Tue, Nov 4, 2008 at 14:43, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> We need to document that, and given that this exists I think we don't need
> to backpatch old versions.
Agreed.
> Beyond that, we need to be very careful with any "solution" that we don't
> upset the moderately fragile security of trusted plperl, and I'm going to
> look fairly skeptically at anything that changes the way we set up and call
> functions. But by all means if you can come up with a robust way of allowing
> the more traditional way of calling sort routines, send it in.
Well its not just sort its anything that uses main:: right?
>Sharing
> globals between the Safe and non-Safe worlds is not a solution - we removed
> an instance of that not long ago for security reasons.
Oh defiantly :) just tossing out ideas. Instead of storing the sub we
could just call Safe::reval() everytime... that seems the safest way
to me.
The other idea Ive been toying this is instead of calling reval we can
just call Opcode::_safe_call_sv() something like the below:
I verified it on perl 5.10.0 only but I looked at 5.8.8 and those
routines in Safe.pm are the same so it should be relatively safe...
Note this is *exactly* what reval does except we already do our own
strict import. and it only works for CODE refs.
*** a/src/pl/plperl/plperl.c
--- b/src/pl/plperl/plperl.c
***
*** 283,295 _PG_init(void)
"&_plperl_to_pg_array " \
"&DEBUG &LOG &INFO &NOTICE &WARNING &ERROR %_SHARED ]);" \
"sub ::mksafefunc {" \
! " my $ret = $PLContainer->reval(qq[sub { $_[0] $_[1] }]); " \
! " $@ =~ s/\\(eval \\d+\\) //g if $@; return $ret; }" \
"$PLContainer->permit(qw[require caller]); $PLContainer->reval('use
strict;');" \
"$PLContainer->deny(qw[require caller]); " \
"sub ::mk_strict_safefunc {" \
! " my $ret = $PLContainer->reval(qq[sub { BEGIN {
strict->import(); } $_[0] $_[1] }]); " \
! " $@ =~ s/\\(eval \\d+\\) //g if $@; return $ret; }"
#define SAFE_BAD \
"use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');" \
--- 283,299
"&_plperl_to_pg_array " \
"&DEBUG &LOG &INFO &NOTICE &WARNING &ERROR %_SHARED ]);" \
"sub ::mksafefunc {" \
! " my $__ExPr__ = $PLContainer->reval(qq[sub { $_[0] $_[1] }]); " \
! " $@ =~ s/\\(eval \\d+\\) //g if $@; " \
! " my $sub = eval 'package '. $PLContainer->{Root} .'; sub {
@_=(); $__ExPr__->(); }'; " \
! " return sub { Opcode::_safe_call_sv($PLContainer->{Root},
$PLContainer->{Mask}, $sub); }; } "\
"$PLContainer->permit(qw[require caller]); $PLContainer->reval('use
strict;');" \
"$PLContainer->deny(qw[require caller]); " \
"sub ::mk_strict_safefunc {" \
! " my $__ExPr__ = $PLContainer->reval(qq[sub { BEGIN {
strict->import(); } $_[0] $_[1] }]); " \
! " $@ =~ s/\\(eval \\d+\\) //g if $@; "\
! " my $sub = eval 'package '. $PLContainer->{Root} .'; sub {
@_=(); $__ExPr__->(); }'; " \
! " return sub { Opcode::_safe_call_sv($PLContainer->{Root},
$PLContainer->{Mask}, $sub); }; }"
#define SAFE_BAD \
"use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');" \
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Tue, Nov 4, 2008 at 15:02, Alex Hunsaker <[EMAIL PROTECTED]> wrote: > The other idea Ive been toying this is instead of calling reval we can > just call Opcode::_safe_call_sv() something like the below: Argh gmail probably ate the whitespace in the patch... see attached plperl_safe.patch Description: Binary data -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Tue, Nov 4, 2008 at 15:02, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 4, 2008 at 14:43, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
But by all means if you can come up with a robust way of allowing
>> the more traditional way of calling sort routines, send it in.
>
> Well its not just sort its anything that uses main:: right?
Err no you're right its only builtins that use main:: sort being the
only one I know of off the top of my head... its a shame
PLContainer->share('$main::a'); does not seem to work..
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Tue, Nov 4, 2008 at 15:17, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>
> Alex Hunsaker wrote:
>> Err no you're right its only builtins that use main:: sort being the
>> only one I know of off the top of my head... its a shame
>> PLContainer->share('$main::a'); does not seem to work..
>>
>
>
> $a and $b are magical *package* variables. See "perldoc perlvar". This has
> nothing whatever to do with main::
Hah right! The perl is strong in this one! =)
I was just remember seeing warnings from typos like:
$ perl -We '$a = $b;'
Name "main::a" used only once: possible typo at -e line 1.
Name "main::b" used only once: possible typo at -e line 1.
... but that's neither here nor there
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Wed, Nov 5, 2008 at 10:54, Andrew Gierth <[EMAIL PROTECTED]> wrote: >> "nathan" == nathan wagner <[EMAIL PROTECTED]> writes: > > nathan> Completely untested speculation based on my knowledge of perl > nathan> and a bit of reading: > > nathan> The reason you can't see $a and $b is that sort internally > nathan> sets these variables in the main package. That is, sort is > nathan> setting $main::a and $main::b, and when you run the plperl > nathan> code in the safe compartment, main:: isn't visible any more. > > Nice theory, but completely wrong: sort creates $a and $b in the > current package, not in main::. current package is main ;) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Wed, Nov 5, 2008 at 11:14, Tom Lane <[EMAIL PROTECTED]> wrote: > Andrew Gierth <[EMAIL PROTECTED]> writes: >> Nice theory, but completely wrong: sort creates $a and $b in the >> current package, not in main::. > > Hmm ... so then why are we seeing a failure? Because Safe runs in a different namespace altogether (part of why its Safe). We build the sub under Safe but then execute it in the real namespace. The patch I posted fixes this but Id like someone with more knowledge of safe to look over it. From a quick cvs log it *looked* like that was Andrew Dunstan which is why I cc'ed him. This is not a Safe bug IMHO its our (ab)use of it that is causing the problem. Of course if its only sort that gets affected maybe the cure is worse than the disease... -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Wed, Nov 5, 2008 at 18:03, Andrew Gierth <[EMAIL PROTECTED]> wrote: >>>>>> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes: > > >> Hmm ... so then why are we seeing a failure? > > [...] > Alex> This is not a Safe bug IMHO its our (ab)use of it that is > Alex> causing the problem. > > Then explain why the problem goes away when you build perl with > threading turned off. Hrm yep i built one without threads problem disappears... Guess Ive just been out to lunch :) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Thu, Nov 6, 2008 at 06:41, Tom Lane <[EMAIL PROTECTED]> wrote: > "Alex Hunsaker" <[EMAIL PROTECTED]> writes: >> On Wed, Nov 5, 2008 at 18:03, Andrew Gierth <[EMAIL PROTECTED]> wrote: >>> Then explain why the problem goes away when you build perl with >>> threading turned off. > >> Hrm yep i built one without threads problem disappears... Guess Ive >> just been out to lunch :) > > So we have an example of a pure-Perl script, with no visible threading > dependency, that behaves differently with and without threads. Who's > filing the bug report? I submitted http://rt.perl.org/rt3/Public/Bug/Display.html?id=60374 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Thu, Nov 6, 2008 at 09:03, Andrew Gierth <[EMAIL PROTECTED]> wrote: >>>>>> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes: > > Alex> I submitted http://rt.perl.org/rt3/Public/Bug/Display.html?id=60374 > > Feel free to add my explanation to that (I couldn't see an obvious way > to do it myself) Added (I think), FYI looks like you should just be able to send a mail to [EMAIL PROTECTED] with [perl #60374] in the subject. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Thu, Nov 6, 2008 at 09:00, Andrew Gierth <[EMAIL PROTECTED]> wrote: > If it helps any, I've tracked down in the perl guts exactly why this > happens: Cool > Notice, though, that without ithreads, the COP points directly to the > stash, but with ithreads, it points instead to the _name_ of the stash > (e.g. "main"). The problem arises because with Safe in use, the > package created by Safe to use as a container _thinks_ that its name > is "main" even though it's not, so the COPs compiled inside it point > to the name "main" rather than to the real name of the container. Ok so I kind of analyzed it right, just missed the threading issue. (namely that its referencing a different main when we execute it outside of "Safe") FYI the commit that changd it is http://perl5.git.perl.org/?p=perl.git;a=commitdiff;h=18537ab8315c273284bfe269f1678095c399c053;hp=89cb812aee601e19db5eb36b2c6e74980a348661 It been this way since 1999 with the descriptive commit message 'avoid stash pointers in optree under USE_ITHREADS' -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Canot instal
Hello, I canot instal a postgre version 8.2.5...I have a 2 clicks on the doc. and appears a box error: This installation package can not be open Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows install package. whats the problem? Reggards, Alex Rezende
[BUGS] ALTER TABLE DISABLE RULE does not work inside of a transaction
Namely it does not disable the rule... Enabling inside of the transaction seems to work though Tried both CVS and 8.3.5... create table trule (a int); insert into trule (a) values (1); create rule trule_rule as on update to trule do instead nothing; update trule set a = 2; UPDATE 0 begin; ALTER TABLE trule DISABLE RULE trule_rule; update trule set a = 2; UPDATE 0 \d trule Table "public.trule" Column | Type | Modifiers +-+--- a | integer | Disabled rules: trule_rule AS ON UPDATE TO trule DO INSTEAD NOTHING rollback; ALTER TABLE trule DISABLE RULE trule_rule; update trule set a = 2; UPDATE 1 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] ALTER TABLE DISABLE RULE does not work inside of a transaction
On Mon, Dec 29, 2008 at 15:07, Alex Hunsaker wrote: > Namely it does not disable the rule... > Enabling inside of the transaction seems to work though Hrm the above turned out to be false... must have gotten confused when testing with triggers If i turn on RELCACHE_FORCE_RELEASE or CLOBBER_CACHE_ALWAYS then it works as expected. Maybe this will make someone who understands the relcache stuff better go Ahh ha! -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bad interval conversion?
On Tue, Aug 18, 2009 at 06:00, hubert depesz lubaczewski wrote: > Hi, > tried on latest 8.5, and some 8.3: > # select '4817191.623 ms'::interval; > interval > -- > -00:35:47.483648 > (1 row) > > I am pretty sure the answer is wrong. But why? It only happens if you have integer date times on... seems to have gotten introduced by http://archives.postgresql.org/pgsql-committers/2008-03/msg00406.php Im thinking the fact that fsec_t is now an int32 on INT64_TIMESTAMP builds was a typo/thinko... its really supposed to be int64. With the attached patch it works correctly and fails with 'out of range' when its actually out of range. *** a/src/include/utils/timestamp.h --- b/src/include/utils/timestamp.h *** *** 46,52 typedef int64 Timestamp; typedef int64 TimestampTz; typedef int64 TimeOffset; ! typedef int32 fsec_t; /* fractional seconds (in microseconds) */ #else typedef double Timestamp; --- 46,52 typedef int64 Timestamp; typedef int64 TimestampTz; typedef int64 TimeOffset; ! typedef int64 fsec_t; /* fractional seconds (in microseconds) */ #else typedef double Timestamp; -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bad interval conversion?
On Tue, Aug 18, 2009 at 10:42, Tom Lane wrote: > Alex Hunsaker writes: >> It only happens if you have integer date times on... seems to have >> gotten introduced by >> http://archives.postgresql.org/pgsql-committers/2008-03/msg00406.php > > Uh, no, fsec_t was int32 before that (look towards the bottom of the > diff). I'm fairly dubious that fixing it as you suggest is a one-liner > --- the width of fsec_t is something that seems likely to propagate all > over. A narrower fix for whatever this specific problem is seems safer. (not to mention it probably breaks ecpg ...) I saw: typedef int32 fsec_t; vs typedef double fsec_t; and thought hrm... that looks odd.. Ok well we can add overflow checks where we need-em. If you don't think the attached patch is horridly ugly- im willing wade through the uses of fsec and apply something similar where we need them. (DTK_SECOND at the very least, but fsec_t stuff is scattered all through adt/) *** a/src/backend/utils/adt/datetime.c --- b/src/backend/utils/adt/datetime.c *** *** 2987,2993 DecodeInterval(char **field, int *ftype, int nf, int range, case DTK_MILLISEC: #ifdef HAVE_INT64_TIMESTAMP ! *fsec += rint((val + fval) * 1000); #else *fsec += (val + fval) * 1e-3; #endif --- 2987,3001 case DTK_MILLISEC: #ifdef HAVE_INT64_TIMESTAMP ! /* !* fval is unused or re-initialized if it is !* needed again */ ! fval = rint((val + fval) * 1000); ! ! if (fval < INT_MIN || fval > INT_MAX) ! return DTERR_FIELD_OVERFLOW; ! ! *fsec += fval; #else *fsec += (val + fval) * 1e-3; #endif *** a/src/backend/utils/adt/datetime.c --- b/src/backend/utils/adt/datetime.c *** *** 2987,2993 DecodeInterval(char **field, int *ftype, int nf, int range, case DTK_MILLISEC: #ifdef HAVE_INT64_TIMESTAMP ! *fsec += rint((val + fval) * 1000); #else *fsec += (val + fval) * 1e-3; #endif --- 2987,3001 case DTK_MILLISEC: #ifdef HAVE_INT64_TIMESTAMP ! /* ! * fval is unused or re-initialized if it is ! * needed again */ ! fval = rint((val + fval) * 1000); ! ! if (fval < INT_MIN || fval > INT_MAX) ! return DTERR_FIELD_OVERFLOW; ! ! *fsec += fval; #else *fsec += (val + fval) * 1e-3; #endif -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bad interval conversion?
On Tue, Aug 18, 2009 at 12:07, Tom Lane wrote: > Throwing overflow errors doesn't seem very nice either, especially not > for values that worked just fine before 8.4. I just checked both 8.3.7 and 8.2.13 give: # select '4817191.623 ms'::interval; interval -- -00:35:47.483648 (1 row) > Seems like a proper fix would involve doing some modulo arithmetic to be > sure that we add the integral seconds to the seconds field and only a > fraction to the fsec field. Ok I looked around at the other fsec assignments in adt/ and did not see any that were not treating them as fractional correctly. This seems to be the only case. Anywho is the below more what you expected? (I decided to do it for the floating point case as well...) With this patch I get (it also passes a make check): # select '4817191.623 ms'::interval; interval - 01:20:17.191623 *** a/src/backend/utils/adt/datetime.c --- b/src/backend/utils/adt/datetime.c *** *** 2986,2991 DecodeInterval(char **field, int *ftype, int nf, int range, --- 2986,2994 break; case DTK_MILLISEC: + tm->tm_sec += val / 1000; + val = val % 1000; + #ifdef HAVE_INT64_TIMESTAMP *fsec += rint((val + fval) * 1000); #else *** a/src/backend/utils/adt/datetime.c --- b/src/backend/utils/adt/datetime.c *** *** 2986,2991 DecodeInterval(char **field, int *ftype, int nf, int range, --- 2986,2994 break; case DTK_MILLISEC: + tm->tm_sec += val / 1000; + val = val % 1000; + #ifdef HAVE_INT64_TIMESTAMP *fsec += rint((val + fval) * 1000); #else -- 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 #5089: not supported plpsql
The following bug has been logged online: Bug reference: 5089 Logged by: Yamashkin Alex Email address: defa...@smart-soft.ru PostgreSQL version: 8.4.0.1 Operating system: windows XP Embeded Description:not supported plpsql Details: good day. installing Postgresql 8.4 on Windows XP Embeded available language construct plpsql requests for functions. What is our problem and how it can solve? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
On Thu, Nov 6, 2008 at 08:37, Alex Hunsaker wrote: > On Thu, Nov 6, 2008 at 06:41, Tom Lane wrote: >> "Alex Hunsaker" writes: >>> On Wed, Nov 5, 2008 at 18:03, Andrew Gierth >>> wrote: >>>> Then explain why the problem goes away when you build perl with >>>> threading turned off. >> >>> Hrm yep i built one without threads problem disappears... Guess Ive >>> just been out to lunch :) >> >> So we have an example of a pure-Perl script, with no visible threading >> dependency, that behaves differently with and without threads. Who's >> filing the bug report? > > I submitted http://rt.perl.org/rt3/Public/Bug/Display.html?id=60374 [ Replying to old thread... ] Tim Bunce managed to get a patch pushed, this is now fixed in Safe v2.20. yay! -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5277: plperl can't get args properly
On Thu, Jan 14, 2010 at 04:06, louis wrote: > Arguments can't be passed to a plperl function Yeah, this is a bug with safe 2.20 :( see -http://rt.perl.org/rt3/Ticket/Display.html?id=72068 I would either try out this fix: http://github.com/timbunce/Safe/commits/master. Or downgrade to 2.19 for now: $ cpan cpan> install RGARCIA/Safe-2.19.tar.gz -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5333: psql returns 0 on error
On Thu, Feb 18, 2010 at 02:20, wrote: > $ psql -U foo -h 127.0.0.1 -f doesntwork.sql db > Password for user foo: > ERROR: invalid byte sequence for encoding "UTF8": 0xe46976 > HINT: This error can also happen if the byte sequence does not match the > encoding expected by the server, which is controlled by "client_encoding". > $ echo $? > 0 You probably want to define ON_ERROR_STOP... see the man page about it. psql -v 'ON_ERROR_STOP=on' ... -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4
On Thu, Feb 18, 2010 at 11:09, Tim Bunce wrote:
> The key line is:
>
> *PLPerl::utf8::SWASHNEW = \&utf8::SWASHNEW;
Hrm... It seems to work for me in HEAD and AFAICS we dont have that
line. Did I just miss it? Or did you happen to fix it in another way
with your refactoring?
Another Idea that comes to mind would be instead of (in ::mksafefunc):
my $subref = ->reval(sub {} );
$subref->();
do:
my $subref = ->reval(sub {});
return sub { ->reval("$subreb->();"); }
or something...
I did a few quick tests but it failed miserably for me... Im also not
fond of adding yet another closure. :)
> This allows the perl regex logic to call the SWASHNEW method that's
> called when information from the Unicode character database is needed.
> (The lack of that method was causing the regex logic to think that the
> utf8 module wasn't loaded, so it would try to 'require' it but fail due
> to the restrictions of the Safe compartment.)
Makes me think we might just be able to share some of utf8 package in the safe?
> The rest of the patch is updates the surrounding code to the same
> simplified 'utf8fix' logic used in PostgreSQL 9.0, and the same Safe
> version checks.
From a quick look it looks ok.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4
On Fri, Feb 19, 2010 at 02:30, Tim Bunce wrote:
> On Thu, Feb 18, 2010 at 11:32:38AM -0700, Alex Hunsaker wrote:
> > On Thu, Feb 18, 2010 at 11:09, Tim Bunce wrote:
> >*PLPerl::utf8::SWASHNEW = \&utf8::SWASHNEW;
> >
> > Hrm... It seems to work for me in HEAD and AFAICS we dont have that
> > line. Did I just miss it? Or did you happen to fix it in another way
> > with your refactoring?
> To be honest I'm not sure. I plan to look into that today.
My hunch is it has to do with the require strict; require feature;
That's the only major difference I see (other than the require_op and
it being in its own package/file).
>> I did a few quick tests but it failed miserably for me... Im also not
>> fond of adding yet another closure. :)
>
> No amount of closure wrapping will fix the problem.
Yeah, brain fart... That's essentially what Safe.pm does now (and why
there is a problem :) )
>> Makes me think we might just be able to share some of utf8 package in the
>> safe?
>
> I tried. The perl utf8.c code does a method lookup of SWASHNEW to decide
> if the utf8 module has been loaded. So if SWASHNEW is shared _before_
> utf8 is loaded *and used* then the method lookup works (it finds the
> shared stub) and the utf8 module never gets loaded.
Hrm... That seems wrong to me. Let me see If I can explain why. The
below is what you seem to be saying:
package utf8;
sub import { # or maybe this is a BEGIN
return if(\&{'utf8::SWASHNEW'}; # already loaded
# ok not loaded open the Unicode database and do junk which will
'trap' in safe
do 'utf8_heavy.pl';
}
So if we define SWASHNEW without loading the unicode database how will
utf8/unicode work exactly? I guess as long as it gets loaded at some
point it works. So for postgres because we do the utf8 fix after
Safe->new and at that point we cant have any 'bad' strings, it will
work. (with your hack). Sound right?
It seems to me a more correct fix would be to require utf8; inside of
the safe like we do strict. Sorry thats a bit handwavy. You have
obviously spent more time then me looking into this...
Im thinking (in pseudo code):
#define SAFE_OK
sub ::mksafefunc {
permit->(qw(caller require));
reval->('require utf8; 1;');
deny->(qw(caller require));
...
}
sub ::mk_strict_safefunc {
...reval->('use strict; require utf8;)
}
static void
plperl_safe_init
{
if (GetDatabaseEncoding() == PG_UTF8)
{
eval_pv("my $a=pack('U',0xC4); $a =~ /\\xE4\\d/i;", FALSE);
}
eval_pv(SAFE_MODULE, FALSE);
eval_pv(SAFE_OK, FALSE)
}
One thing that stinks is while we might not do the utf8fix if we are
not PG_UTF8 we would always require utf8;. And I dont see an easy way
around that in 8.4 :( Also note that is all entirely untested :( If
you think its sane (and it might not be) Im happy to work up a patch.
Id favor this approach as if you have utf8 strings the likely hood
that you want ::upgrade, ::downgrade, ::encode, ::valid or ::is_utf8
is fairly high. Then again, no one has complained thus far... Maybe
thats just me :)
Thoughts?
Anywhoo I cant reproduce this outside of postgres. Maybe you can give
me a pointer?
use Safe();
binmode(STDOUT, ':utf8');
print $Safe::VERSION . "\n";
my $safe = Safe->new('t');
$safe->permit('print');
$safe->reval('sub { print "\x{263a}\n"; }')->();
print $@ ."\n" if($@);
-
2.22
☺
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4
On Fri, Feb 19, 2010 at 06:06, Tim Bunce wrote:
> I've got the patch to Safe ready but the more I think about it the more
> I think the right fix is for Safe to automatically fully load utf8.pm
> (and utf8_heavy.pl) and to always share SWASHNEW itself.
It seems cleaner if we could just share say utf8::VERSION. SWASHNEW
seems likely to be changed as it "feels" more like a implementation
detail. But if thats what utf8 checks... well then thats what it
checks.
> Assuming perl5-porters agree then the next release of Safe will do that
> ad this patch won't be needed. (Other than it possibly being worthwhile
> to detect the 'bad' versions of Safe.)
It seems safer if there was some way to 'opt' in say if utf8 was
loaded then make safe do the above. Or maybe a pragma? use utf8
qw(utf8); We would still have to patch postgres... But I can
imagine there are some users of utf8 that dont want utf8 strings. BTW
as I could not reproduce this does this mean that reval->('"\x{}...")
works while reval->('sub { "\x{}"}') does not ? Or is it before the
first one failed while the closure based one worked?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4
On Fri, Feb 19, 2010 at 09:18, Alex Hunsaker wrote: > It seems to me a more correct fix would be to require utf8; inside of > the safe like we do strict. > > Id favor this approach as if you have utf8 strings the likely hood > that you want ::upgrade, ::downgrade, ::encode, ::valid or ::is_utf8 > is fairly high. Then again, no one has complained thus far... Maybe > thats just me :) On second thought, I dont think we should import any of those by default. And your hack for just SWASHNEW is better. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4
On Fri, Feb 19, 2010 at 14:00, Tim Bunce wrote:
> On Fri, Feb 19, 2010 at 09:32:38AM -0700, Alex Hunsaker wrote:
>> On Fri, Feb 19, 2010 at 09:18, Alex Hunsaker wrote:
>> > It seems to me a more correct fix would be to require utf8; inside of
>> > the safe like we do strict.
>> >
>> > Id favor this approach as if you have utf8 strings the likely hood
>> > that you want ::upgrade, ::downgrade, ::encode, ::valid or ::is_utf8
>> > is fairly high. Then again, no one has complained thus far... Maybe
>> > thats just me :)
>>
>> On second thought, I dont think we should import any of those by
>> default. And your hack for just SWASHNEW is better.
Funny.. Safe.pm already does this (share various utf8:: functions) so
I think there should be no question that what you did in the patch
below is correct and a bug with Safe. Sorry for the handwaves, that
was me trying to understand the problem and your fix. :)
> Here's the corresponding perlbug
> http://rt.perl.org/rt3/Ticket/Display.html?id=72942
Hrm... Is the require utf8; strictly needed? A reading of perldoc utf8
seems to say the do { my $unicode = ... } (aka load utf8_heavy.pl)
part should make it all work fine.
It also seems to still work
t/safeutf8.t ... ok
*shrug*
> I'll retest 8.4 and 9.0 against this on Monday.
Ill see if I can squeeze in some pg 8.4 perl 5.10.1 linux x86_64
testing tonight of the above. (Ill just reply to the perl bug )
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5339: Version of Perl detected incorrectly
On Mon, Feb 22, 2010 at 10:57, Jonathan wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5339
> Logged by: Jonathan "Duke" Leto
> Email address: jonat...@leto.net
> PostgreSQL version: master 0f50d482
> Operating system: CentOS 5.4 (Linux kernel 2.6.18)
> Description: Version of Perl detected incorrectly
> Details:
>
> $ perl -v
>
> This is perl 5, version 11, subversion 4 (v5.11.4-114-ga4cc961*) built for
> x86_64-linux
...
> checking for perl... /home/leto/bin/perl
> configure: using perl
> configure: WARNING:
> *** The installed version of Perl, /home/leto/bin/perl, is too old to use
> with PostgreSQL.
> *** Perl version 5.8 or later is required, but this is .
Yeah find the below which attempts to clean this up a bit. Instead of
parsing perl -v output, we just "use" the min required version and
rely on perl error out for us. Its also more or less what we do at
runtime in plc_perl_boot.pl now.
Thoughts?
*** a/configure
--- b/configure
***
*** 6867,6884 fi
fi
if test "$PERL"; then
! pgac_perl_version=`$PERL -v 2>/dev/null | sed -n 's/This is perl,
v[a-z ]*//p' | sed 's/ .*//'`
! { $as_echo "$as_me:$LINENO: using perl $pgac_perl_version" >&5
! $as_echo "$as_me: using perl $pgac_perl_version" >&6;}
! if echo "$pgac_perl_version" | sed 's/[.a-z_]/ /g' | \
! $AWK '{ if ($1 = 5 && $2 >= 8) exit 1; else exit 0;}'
! then
{ $as_echo "$as_me:$LINENO: WARNING:
*** The installed version of Perl, $PERL, is too old to use with PostgreSQL.
! *** Perl version 5.8 or later is required, but this is
$pgac_perl_version." >&5
$as_echo "$as_me: WARNING:
*** The installed version of Perl, $PERL, is too old to use with PostgreSQL.
! *** Perl version 5.8 or later is required, but this is
$pgac_perl_version." >&2;}
PERL=""
fi
fi
--- 6867,6880
fi
if test "$PERL"; then
! perl_version_error=`$PERL -e 'use 5.00801;' 2>&1`
! if test -n "$perl_version_error"; then
{ $as_echo "$as_me:$LINENO: WARNING:
*** The installed version of Perl, $PERL, is too old to use with PostgreSQL.
! *** $perl_version_error." >&5
$as_echo "$as_me: WARNING:
*** The installed version of Perl, $PERL, is too old to use with PostgreSQL.
! *** $perl_version_error." >&2;}
PERL=""
fi
fi
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5339: Version of Perl detected incorrectly
On Mon, Feb 22, 2010 at 12:44, Alex Hunsaker wrote: > On Mon, Feb 22, 2010 at 10:57, Jonathan wrote: >> configure: using perl >> configure: WARNING: >> *** The installed version of Perl, /home/leto/bin/perl, is too old to use >> with PostgreSQL. >> *** Perl version 5.8 or later is required, but this is . > > Yeah find the below which attempts to clean this up a bit. For the curious this what it looks like after (I of course bumped the check to the non-existent perl 5.11.10 version): configure: WARNING: *** The installed version of Perl, /usr/bin/perl, is too old to use with PostgreSQL. *** Perl v5.11.10 required--this is only v5.10.1, stopped at -e line 1. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5339: Version of Perl detected incorrectly
On Mon, Feb 22, 2010 at 13:07, Tom Lane wrote:
> Alex Hunsaker writes:
>> ! perl_version_error=`$PERL -e 'use 5.00801;' 2>&1`
>
> This is not a path towards an acceptable solution, as it effectively
> assumes what we are setting out to prove, namely that we have found
> a reasonably modern version of perl. Try it in perl 4...
Well I would if I had it sitting around =). I did try to compile
one... but chickened out as soon as I hit an error:
$ make
`sh cflags perly.o` perly.c
CCCMD = cc -c -O
In file included from perly.y:38:
perl.h:279: error: conflicting types for ‘sys_errlist’
/usr/include/bits/sys_errlist.h:28: note: previous declaration of
‘sys_errlist’ was here
In file included from perl.h:540,
from perly.y:38:
arg.h:685:1: warning: "AF_LOCAL" redefined
In file included from /usr/include/sys/socket.h:40,
from /usr/include/netinet/in.h:25,
from perl.h:224,
from perly.y:38:
/usr/include/bits/socket.h:116:1: warning: this is the location of the
previous definition
How about something like the below? Basically If we find "This is
perl v4" we bail right then. Otherwise we use the version check I
proposed up-thread? I may have inadvertently used some
bash/gnu-isms... sorry about that.
*** a/configure
--- b/configure
***
*** 6867,6884 fi
fi
if test "$PERL"; then
! pgac_perl_version=`$PERL -v 2>/dev/null | sed -n 's/This is perl,
v[a-z ]*//p' | sed 's/ .*//'`
! { $as_echo "$as_me:$LINENO: using perl $pgac_perl_version" >&5
! $as_echo "$as_me: using perl $pgac_perl_version" >&6;}
! if echo "$pgac_perl_version" | sed 's/[.a-z_]/ /g' | \
! $AWK '{ if ($1 = 5 && $2 >= 8) exit 1; else exit 0;}'
! then
{ $as_echo "$as_me:$LINENO: WARNING:
*** The installed version of Perl, $PERL, is too old to use with PostgreSQL.
! *** Perl version 5.8 or later is required, but this is
$pgac_perl_version." >&5
$as_echo "$as_me: WARNING:
*** The installed version of Perl, $PERL, is too old to use with PostgreSQL.
! *** Perl version 5.8 or later is required, but this is
$pgac_perl_version." >&2;}
PERL=""
fi
fi
--- 6867,6885
fi
if test "$PERL"; then
! perl_version_error=""
! if $PERL -v 2>/dev/null | grep -q 'This is perl, v4' 2>/dev/null; then
! perl_version_error="Perl version 5.8 or later is required, but
this is perl v4"
! else
! perl_version_error=`$PERL -e 'use 5.00801;' 2>&1`
! fi
! if test -n "$perl_version_error"; then
{ $as_echo "$as_me:$LINENO: WARNING:
*** The installed version of Perl, $PERL, is too old to use with PostgreSQL.
! *** $perl_version_error." >&5
$as_echo "$as_me: WARNING:
*** The installed version of Perl, $PERL, is too old to use with PostgreSQL.
! *** $perl_version_error." >&2;}
PERL=""
fi
fi
Thoughts?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5339: Version of Perl detected incorrectly
On Mon, Feb 22, 2010 at 14:17, Alex Hunsaker wrote: > On Mon, Feb 22, 2010 at 13:07, Tom Lane wrote: >> Alex Hunsaker writes: >>> ! perl_version_error=`$PERL -e 'use 5.00801;' 2>&1` ... > How about something like the below? Find attached one that modifies config/perl.m4 as well :) perl_configure_check.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5339: Version of Perl detected incorrectly
On Mon, Feb 22, 2010 at 14:31, Tom Lane wrote: > Alex Hunsaker writes: >> How about something like the below? > > I still think that this is optimizing the wrong thing. We care about > the clarity of the message the user sees, not about how short or clean > the Perl code is. I'm inclined to stay with the same basic > implementation and just hack up the regexp some more to cope with 5.11's > more verbose -v output. Cant argue with that. However, I dont think my sed foo is up to the challenge ATM. :) BTW this is the perl commit that changed it: commit ded326e4b6fad7e2479796691d0c27b89d2fe080 Author: David Golden Date: Thu Nov 12 10:46:30 2009 -0500 Change perl -v version format New format: This is perl 5, version 11, subversion 1 (v5.11.1) ... The rationale for this change is that the Perl 5 interpreter will never increment PERL_REVISION from 5 to 6, so we want people to start focusing on the PERL_VERSION number as most significant and PERL_SUBVERSION as equivalent to a "release number". In other words, "perl 5" is a language, this is the 11th version of it, and the second release of that version (counting from zero). Among other things, this makes the output of -v and -V more consistent. The old v-string style is included for familiarity and usage in code. For builds from git, it will include the same extended format as it did before, e.g. "(v5.11.1-176-gaf24cc9*)" -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5339: Version of Perl detected incorrectly
On Mon, Feb 22, 2010 at 14:31, Tom Lane wrote:
> I'm inclined to stay with the same basic
> implementation and just hack up the regexp some more to cope with 5.11's
> more verbose -v output.
And here is a stab at that:
$ echo "This is perl, version 4.0" | sed -n 's/This is perl.*v[a-z
]*\([0-9]\.[\.0-9]*\).*$/\1/p'
4.0
$ echo "This is perl, v5.8.0" | sed -n 's/This is perl.*v[a-z
]*\([0-9]\.[\.0-9]*\).*$/\1/p'
5.8.0
$ echo "This is perl, v5.10.1" | sed -n 's/This is perl.*v[a-z
]*\([0-9]\.[\.0-9]*\).*$/\1/p'
5.10.1
$ echo "This is perl 5, version 11, subversion 4
(v5.11.4-114-ga4cc961*) built for" | sed -n 's/This is perl.*v[a-z
]*\([0-9]\.[\.0-9]*\).*$/\1/p'
5.11.4
---
*** config/perl.m4
--- config/perl.m4
***
*** 10,16 if test -z "$PERL"; then
fi
if test "$PERL"; then
! pgac_perl_version=`$PERL -v 2>/dev/null | sed -n ['s/This is perl,
v[a-z ]*//p'] | sed ['s/ .*//']`
AC_MSG_NOTICE([using perl $pgac_perl_version])
if echo "$pgac_perl_version" | sed ['s/[.a-z_]/ /g'] | \
$AWK '{ if ([$]1 = 5 && [$]2 >= 8) exit 1; else exit 0;}'
--- 10,16
fi
if test "$PERL"; then
! pgac_perl_version=`$PERL -v 2>/dev/null | sed -n ['s/This is
perl.*v[a-z ]*\([0-9]\.[\.0-9]*\).*$/\1/p']`
AC_MSG_NOTICE([using perl $pgac_perl_version])
if echo "$pgac_perl_version" | sed ['s/[.a-z_]/ /g'] | \
$AWK '{ if ([$]1 = 5 && [$]2 >= 8) exit 1; else exit 0;}'
*** configure
--- configure
***
*** 6867,6873 fi
fi
if test "$PERL"; then
! pgac_perl_version=`$PERL -v 2>/dev/null | sed -n 's/This is perl,
v[a-z ]*//p' | sed 's/ .*//'`
{ $as_echo "$as_me:$LINENO: using perl $pgac_perl_version" >&5
$as_echo "$as_me: using perl $pgac_perl_version" >&6;}
if echo "$pgac_perl_version" | sed 's/[.a-z_]/ /g' | \
--- 6867,6873
fi
if test "$PERL"; then
! pgac_perl_version=`$PERL -v 2>/dev/null | sed -n 's/This is
perl.*v[a-z ]*\([0-9]\.[\.0-9]*\).*$/\1/p'`
{ $as_echo "$as_me:$LINENO: using perl $pgac_perl_version" >&5
$as_echo "$as_me: using perl $pgac_perl_version" >&6;}
if echo "$pgac_perl_version" | sed 's/[.a-z_]/ /g' | \
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5339: Version of Perl detected incorrectly
On Tue, Feb 23, 2010 at 00:50, Alex Hunsaker wrote:
> On Mon, Feb 22, 2010 at 14:31, Tom Lane wrote:
>> I'm inclined to stay with the same basic
>> implementation and just hack up the regexp some more to cope with 5.11's
>> more verbose -v output.
>
> And here is a stab at that:
Grr... stupid word wrapping. Attached.
*** config/perl.m4
--- config/perl.m4
***
*** 10,16 if test -z "$PERL"; then
fi
if test "$PERL"; then
! pgac_perl_version=`$PERL -v 2>/dev/null | sed -n ['s/This is perl, v[a-z ]*//p'] | sed ['s/ .*//']`
AC_MSG_NOTICE([using perl $pgac_perl_version])
if echo "$pgac_perl_version" | sed ['s/[.a-z_]/ /g'] | \
$AWK '{ if ([$]1 = 5 && [$]2 >= 8) exit 1; else exit 0;}'
--- 10,16
fi
if test "$PERL"; then
! pgac_perl_version=`$PERL -v 2>/dev/null | sed -n ['s/This is perl.*v[a-z ]*\([0-9]\.[\.0-9]*\).*$/\1/p']`
AC_MSG_NOTICE([using perl $pgac_perl_version])
if echo "$pgac_perl_version" | sed ['s/[.a-z_]/ /g'] | \
$AWK '{ if ([$]1 = 5 && [$]2 >= 8) exit 1; else exit 0;}'
*** configure
--- configure
***
*** 6867,6873 fi
fi
if test "$PERL"; then
! pgac_perl_version=`$PERL -v 2>/dev/null | sed -n 's/This is perl, v[a-z ]*//p' | sed 's/ .*//'`
{ $as_echo "$as_me:$LINENO: using perl $pgac_perl_version" >&5
$as_echo "$as_me: using perl $pgac_perl_version" >&6;}
if echo "$pgac_perl_version" | sed 's/[.a-z_]/ /g' | \
--- 6867,6873
fi
if test "$PERL"; then
! pgac_perl_version=`$PERL -v 2>/dev/null | sed -n 's/This is perl.*v[a-z ]*\([0-9]\.[\.0-9]*\).*$/\1/p'`
{ $as_echo "$as_me:$LINENO: using perl $pgac_perl_version" >&5
$as_echo "$as_me: using perl $pgac_perl_version" >&6;}
if echo "$pgac_perl_version" | sed 's/[.a-z_]/ /g' | \
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
On Tue, Feb 23, 2010 at 15:23, Tim Bunce wrote:
> I believe (but haven't yet confirmed) that the problem here is recursion.
> This affects all versions of PostgreSQL.
Hrm... This seems to work for me in HEAD. It certainly breaks in 8.3.
Am I missing something?
$ bin/psql postgres
psql (9.0devel)
Type "help" for help.
postgres=# CREATE OR REPLACE FUNCTION foo( integer) RETURNS SETOF INT
LANGUAGE plperl AS $$ $$;
CREATE FUNCTION
postgres=# \q
$ bin/psql postgres
psql (9.0devel)
Type "help" for help.
postgres=# CREATE OR REPLACE FUNCTION try() RETURNS VOID LANGUAGE plperl AS $$
my $sth = spi_query("SELECT id FROM foo( 0 ) AS g(id)");
while( my $row = spi_fetchrow($sth) ) {
}
$$;
CREATE FUNCTION
postgres=# SELECT try();
try
-
(1 row)
Seems like assuming I did the above correctly we just have a bug in
the older branches where the "SELECT id FROM foo(0)..." part is
getting compiled/executed in the wrong perl context. In-fact I would
not be surprised at all if there are other dragons lurking when plperl
calls something that tries to compile/call a plperl function. Safe
>2.20 or older.
Ill keep digging.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
On Wed, Feb 24, 2010 at 19:17, Alex Hunsaker wrote:
> On Tue, Feb 23, 2010 at 15:23, Tim Bunce wrote:
>
>> I believe (but haven't yet confirmed) that the problem here is recursion.
>> This affects all versions of PostgreSQL.
> Ill keep digging.
Ok I understand now, basically the problem is (as Tim also described elsewhere):
postgres->plperl_call_perl_func->SPI->postgres->plperl_create_sub
On that last call to plperl_create_sub we are still executing under
Safe (as its the same interpreter). And so it fails when it tries to
compile a new sub.
ISTM the easiest and safest fix would be to not allow recursive plperl
creations. You could still call plperl functions within functions,
just not if they are not defined. This limitation really blows so im
hoping someone else has a better idea? Alternately we could also
break out of the safe, compile the sub and then go back to it as Tim
suggested up-thread. I think this could work as long as its not to
nasty (which Tim does not seem to think it would be).
Thoughts? Better Ideas?
[ patch against 8.3/8.4 ]
*** a/src/pl/plperl/plperl.c
--- b/src/pl/plperl/plperl.c
***
*** 126,131 static HTAB *plperl_proc_hash = NULL;
--- 126,132
static HTAB *plperl_query_hash = NULL;
static bool plperl_use_strict = false;
+ static bool plperl_executing = false;
/* this is saved and restored by plperl_call_handler */
static plperl_call_data *current_call_data = NULL;
***
*** 1117,1125 plperl_call_perl_func(plperl_proc_desc *desc,
FunctionCallInfo fcinfo)
--- 1118,1132
}
PUTBACK;
+ if (desc->lanpltrusted)
+ plperl_executing = true;
+
/* Do NOT use G_KEEPERR here */
count = perl_call_sv(desc->reference, G_SCALAR | G_EVAL);
+ if (desc->lanpltrusted)
+ plperl_executing = false;
+
SPAGAIN;
if (count != 1)
***
*** 1697,1702 compile_plperl_function(Oid fn_oid, bool is_trigger)
--- 1704,1721
check_interp(prodesc->lanpltrusted);
+ /
+* Dont let us recursively create a plperl function from a
plperl function
+* as plperl_create_sub gets called we are running under Safe
and fails.
+* TODO: We could break out of the safe via Safe::HOLE or some
such.
+/
+ if (prodesc->lanpltrusted && plperl_executing)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+errmsg("could not create plperl function
\"%s\"", prodesc->proname),
+errdetail("plperl functions can not
recursivley define other
plperl functions"),
+errhint("try calling the function first")));
+
prodesc->reference = plperl_create_sub(prodesc->proname,
proc_source,
prodesc->lanpltrusted);
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
On Wed, Feb 24, 2010 at 20:19, Tom Lane wrote: >What you're saying, IIUC, is > that if function A calls function B via a SPI command, and B wasn't > executed previously in the current session, it would fail? Seems > entirely unacceptable. Yep, thats right :(. Thanks, thats exactly the kind of feedback I wanted to get. I think we will see if we can get this fixed on the Safe/perl side then. Tim, I think unless the Safe::Hole stuff is really straight forward it seems like (as we previously agreed) the best change is to revert safe to its old behavior for now. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
On Wed, Feb 24, 2010 at 20:37, Alex Hunsaker wrote:
> On Wed, Feb 24, 2010 at 20:19, Tom Lane wrote:
>> Seems entirely unacceptable.
> I think we will see if we can get this fixed on the Safe/perl side then.
BTW the trade off here is we revert back to sort { $a <=> $b } not
working. That is if you could call it a trade off... The level of
breaking is not really comparable :)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
On Tue, Feb 23, 2010 at 15:54, Tim Bunce wrote:
> Doesn't seem too icky. Basically plperl would need to save the values of
> PL_defstash, PL_incgv and PL_op_mask when a plperl interpreter is
> initialized. And then local()'ly restore them in the plperl entry points.
> Should only be a few lines of code - in theory :)
Ok I can get behind this. I did some testing and we could probably
even store less than than that if we could do the equivalent of:
Safe->share('::mksafefunc');
pl_perl_createsub()
Safe->unshare('::mksafefunc');
See my quick test case:
my $s = Safe->new();
$s->permit(qw(print));
our $obj = sub { return eval 'sub { print "b\n";}' };
$obj->()->();
$s->share(qw($obj));
$s->reval('$obj->()->();');
print $@ . "\n";
---
b
b
(BTW the above fails with the helpful "Undefined subroutine &main::
called at (eval 6) line 1." without the ->permt(qw(print))")
So we might not even have to store anything if we can make it behave
as above. However I think it will be cleaner to me to locally restore
them as your originally suggested.
BTW sorry for my scatter braininess. I keep flip flopping between
revet Safe or patch postgres. ATM it seems if the patch is simple we
can get it back patched and into 9.0. So my vote is lets try that, if
its to hard then lets see about reverting Safe. Sound Ok?
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
On Wed, Feb 24, 2010 at 22:01, Alex Hunsaker wrote:
> Ok I can get behind this. I did some testing and we could probably
> even store less than than that if we could do the equivalent of:
> Safe->share('::mksafefunc');
> pl_perl_createsub()
> Safe->unshare('::mksafefunc');
On 2nd thought this basically requires your fix anyway. To make it so
you can share something in safe from within safe means we will need to
enable more opcodes there... so it would end up being the same
solution.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
On Thu, Feb 25, 2010 at 12:20, Tom Lane wrote:
> Alex Hunsaker writes:
>> 3) patch postgres to fix the recursive issue (What I'm leaning towards)
>> [ fixes both issues ]
>
> How exactly would you propose doing that?
Well that's the thing, probably by what I described below that. Namely
get something working for 9.1 and after we know its good and solid see
if we can back patch it. Unfeasible? If its really really simple and
straight forward maybe we can find a -commiter willing to commit it
sooner. But I'm dubious. I think the feeling between me and Tim is
patching postgres is a last resort... Maybe if its to fix both sort
{} and this it might be worth it. (That's at least how I parsed what
you said :) ). Ill see if I can figure something out via straight
Safe tonight.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
On Thu, Feb 25, 2010 at 11:04, David E. Wheeler
wrote:
> There seem to be no good answers here.
Yeah, Here is the thing I don't think we can fix 'safe' or even patch
perl to get recursive calls to work. Maybe Tim sees a way? We can
work around it in 9.0 with plperl.on_init. But breaking the back
branches makes it a non-starter.
Basically the problem as I see it is:
1) we call a plperl function which makes perl safe by denying certain
perl operations such as eval.
2) now that the interpreter is in that context, we try to compile a
new sub (using eval) and it fails.
I just don't see a way to make it work without making Safe useless.
For instance we could import the function that compiles the perl sub
into the safe. But then anyone could call it and eval in random code.
Maybe Tim has something up his sleeve? (That does not require plperl.on_init?)
Here are the options I see:
1) revert safe to pre 2.2x behavior breaking sort {}, but fixing this
issue. There would be a new function or a way to opt-in to the new
2.2x secure behavior (which would also fix sort, but this issue would
remain). (Tim's favored ATM)
[ breaks sort ]
2) patch perl to fix the sort {} issue (last I looked it would be
quite invasive and I think I would have a hard time getting it into
blead let alone 5.10.2 and 5.8.10), this issue would still be broken
[ still need to revert safe ]
3) patch postgres to fix the recursive issue (What I'm leaning towards)
[ fixes both issues ]
4) patch postgres to fix the *a, *b issue
[ still need to revert safe ]
5) make safe default import *a, *b to fix sort {} (rejected in the past)
[ still need to revert safe]
6) we might be able to do something in Safe to work around this... I
have an idea or two but I don't think they will pan out. (Basically it
used to work because we were only in the Safe context for that sub {},
we might be able to restore that behavior somehow. that would fix
both issues... I don't have any bright ideas at the moment)
Ill also point out Tim has more or less pointed out all these
solutions up-thread as well.
Anyone see any other options? There are hybrid solutions here. For
instance if we did #1, we could also prepare a patch for 9.1 that will
'opt-in' for the more secure closures and the sort {} fixes. The
patch would in essence be #3. After that's been field tested for a
while we could see about back patching it.
If wishes were horses we'd all be eating steak.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
On Thu, Feb 25, 2010 at 12:59, Greg Sabino Mullane wrote: > Just don't break anything in 9.0 that relies on plperl please. :) To that > end, let me know when HEAD has something somewhat stable, and I'll > run some tests against it (e.g. Bucardo, which uses lots of plperl) Defiantly, the goal is to not break anything :). -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
On Thu, Feb 25, 2010 at 13:03, Alex Hunsaker wrote: > On Thu, Feb 25, 2010 at 12:59, Greg Sabino Mullane wrote: >> Just don't break anything in 9.0 that relies on plperl please. :) To that >> end, let me know when HEAD has something somewhat stable, and I'll >> run some tests against it (e.g. Bucardo, which uses lots of plperl) > > Defiantly, the goal is to not break anything :). Err oops, as David Fetter pointed out... I *think* i meant to say definitely. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
On Thu, Feb 25, 2010 at 12:31, David E. Wheeler
wrote:
> I think Tom meant, what sorts of changes to PostgreSQL do you think might
> solve the problem?
Here is what Tim said:
>Doesn't seem too icky. Basically plperl would need to save the values of
>PL_defstash, PL_incgv and PL_op_mask when a plperl interpreter is
>initialized. And then local()'ly restore them in the plperl entry points.
>Should only be a few lines of code - in theory :)
Basically when we go to compile a new plperl sub we would 'break' out
of the safe, compile the sub (which it itself would go back into the
safe) and then because we local()ly set/restore we would be reset to
the same context when we returned.
Not only is there some prior art for this method (Safe::Hole). After
playing with it a bit last night I agree it should be fairly small and
simple. Im a bit worried there might be some corner cases. All the
easy ones I see cant happen with plperl only with arbitrary 3rd party
modules. Things we might need to do in addition would be: ignoring
END blocks, saving PL_curstash, Invalidating the ISA and method
caches, saving/restoring INC... And that would only be because im
worried there might be some strange issues with the new
plperl.plperl_init. Its hand waving at this point.
Another way I played with last night is calling
Opcode::_save_call_sv("main", Opcode::full_ops, sub_to_compile)
directly instead of perl_call_sv() to compile the sub (or in
pl/plperl.c plperl_create_sub replace the call to perl_call_sv with
Opcode::_safe_call_sv). It should be even simpler and safer. We
would still need to save and local() a few things... But it should
work.
Anyway, im hoping to look at this more tonight... My lunch is over :)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
On Thu, Feb 25, 2010 at 14:06, David E. Wheeler wrote: > On Feb 25, 2010, at 12:58 PM, Tim Bunce wrote: >> There is one fairly good answer: >> >> Use a perl that's compiled to support multiplicity but not threads. > That solves the problem with recursion or with $a and $b or both? Yes ATM because we only kick in the extra security if you are on threads... Its a bit of a kludge in Safe. I know Tim wants to rectify that... -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5352: Bug in PL/PgSQL "SELECT .. INTO" statement parser
On Mon, Mar 1, 2010 at 02:22, Oleg wrote: > CREATE OR REPLACE FUNCTION "bug" () RETURNS pg_catalog.void AS > $body$ > DECLARE > row_test1 test1%rowtype; > row_test2 test2%rowtype; > BEGIN > SELECT test1, chunk_id > FROM test1 JOIN test2 ON(chunk.id = test2.chunk_id) > LIMIT 1 > INTO row_test1, row_test2; *shrug* it works if you put the INTO after SELECT. From the manual: http://www.postgresql.org/docs/current/static/plpgsql-statements.html#PLPGSQL-SELECT-INTO : The INTO clause can appear almost anywhere in the SQL command. Customarily it is written either just before or just : after the list of select_expressions in a SELECT command, or at the end of the command for other command types. : It is recommended that you follow this convention in case the PL/pgSQL parser becomes stricter in future versions. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] bool: symbol name collision
On Tue, May 11, 2010 at 12:42, Robert Haas wrote: > I guess the question that comes to mind for me is how many other > things fall into this category. We define a lot of symbols like int4 > and int32 that other people could also have defined, and I don't > really want to s/^/pg/ all of them. If it's really only a question of > renaming bool I could see doing it. You mean i'd get the pleasure of 'fixing' all my 3rd party C modules? Not that that is a huge problem, we have broken calling conventions in most releases... -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] select fails on indexed varchars.
Hi,
First off I'm running:
links=# select version() ;
version
-
PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66
(1 row)
Now, if I have a table with an index, I'm not able to do some selects on
it. To reproduce:
links=# create table foo ( a char(25) );
CREATE
links=# create index foodx on foo (a);
CREATE
links=# insert into foo values ('Test/Test');
INSERT 29689 1
links=# select * from foo;
a
---
Test/Test
(1 row)
links=# select * from foo where a like 'Test/%'
links-# ;
a
---
(0 rows)
# Strange result, why 0 rows, the select failed.
links=# select * from foo where a like 'Test%';
a
---
Test/Test
(1 row)
# This one's fine.
links=# select * from foo where a like 'Test/T%';
a
---
Test/Test
(1 row)
# And so is this one.
It seems the /% causes a problem. If I drop the index, the selects work
fine. Is this a bug, am I missing something? If you need any other
system info, please let me know. I did an RPM install on a pretty plain
Redhat 6.2 system.
Please reply to [EMAIL PROTECTED] with any ideas.
Thanks!
Alex
---- Gossamer Threads Inc. --
Alex KrohnEmail: [EMAIL PROTECTED]
Internet Consultant Phone: (604) 687-5804
http://www.gossamer-threads.com Fax : (604) 687-5806
Re: [BUGS] select fails on indexed varchars.
Hi, > Alex Krohn <[EMAIL PROTECTED]> writes: > >> Beware of changing the postmaster's locale on the fly, however, > >> since that will leave you with corrupted (out-of-order) indexes. > >> Safest to dump/initdb in new locale/reload. > > > How would I go about changing that? Setting LANG and LC_ALL in the pgsql > > users home directory .bashrc? Or do I need to edit the startup file? > > I'd recommend setting LANG/LC_xxx directly in the script you use to fire > up the postmaster. This ensures it will be right no matter whether the > postmaster is launched by a boot script, by hand by someone logged in as > pgsql, by hand by someone su'd from another account with different > locale, yadda yadda. So I added: LANG=C LC_ALL=C to the /etc/rc.d/init.d/postgres file and stop, restarted the server. I then dropped and recreated the database. However still same results. Is this only my installation that has this problem? It's just a very plain RedHat 6.2 with rpm'd install of Postgres, so I'm a little wary about how many other people will be having this problem as well. Cheers, Alex Gossamer Threads Inc. -- Alex KrohnEmail: [EMAIL PROTECTED] Internet Consultant Phone: (604) 687-5804 http://www.gossamer-threads.com Fax : (604) 687-5806
Re: [BUGS] select fails on indexed varchars.
Hi, > > So I added: > > LANG=C > > LC_ALL=C > > to the /etc/rc.d/init.d/postgres file and stop, restarted the server. I > > then dropped and recreated the database. However still same results. > > LC_COLLATE overrides LC_ALL, I think --- didn't you previously show us > that all the LC_xxx family variables were set in your default > environment? You may need to set (or unset if you prefer) all of 'em. > > Also, I'd really recommend an initdb, not the above half-baked approach, > because the above will not fix any problems that the template1 indexes > might have with a changed sort order. I added to the startup file: LANG=C LC_CTYPE=C LC_NUMERIC=C LC_TIME=C LC_COLLATE=C LC_MONETARY=C LC_MESSAGES=C LC_ALL=C as well as to the postgres users default environment. I then shut down postmaster, and as user postgres ran `initdb /var/lib/pgsql`. I then ran /etc/rc.d/init.d/postgres start as root, and then as user postgres ran `createdb mytest`. After this, my create test and select still produced the same error. Ugh. Cheers, Alex
Re: [BUGS] select fails on indexed varchars.
Hi Tom, > Alex Krohn <[EMAIL PROTECTED]> writes: > > links=# select * from foo where a like 'Test/%' > > links-# ; > > a > > --- > > (0 rows) > > This looks like an artifact of the known problems with LIKE index > optimization in non-ASCII locales. What locale are you running the > postmaster in? Is this what you are looking for: [postgres@penguin pgsql]$ locale LANG=en_US LC_CTYPE="en_US" LC_NUMERIC="en_US" LC_TIME="en_US" LC_COLLATE="en_US" LC_MONETARY="en_US" LC_MESSAGES="en_US" LC_ALL=en_US [postgres@penguin pgsql]$ Postmaster is running as user pgsql. Any ideas on workarounds? Cheers, Alex
Re: [BUGS] select fails on indexed varchars.
Hi Tom, > > I added to the startup file: > > LANG=C > > LC_CTYPE=C > > LC_NUMERIC=C > > LC_TIME=C > > LC_COLLATE=C > > LC_MONETARY=C > > LC_MESSAGES=C > > LC_ALL=C > > Seems reasonable. It's possible you needed "export" commands in there > too, but I wouldn't have thought so (anything coming in from the outer > environment should be exported already). > > > After this, my create test and select still produced the same error. Ugh. > > Hm, maybe I'm barking up the wrong tree. Let's try a direct test. > What do you get from > > select 'a_b'::text < 'ac'::text; > > select 'A_B'::text < 'ac'::text; > > On my machine, these produce 't' in C locale, but 'f' in en_US locale. Seem to be in C locale: links=# select 'a_b'::text < 'ac'::text; ?column? -- t (1 row) links=# select 'A_B'::text < 'ac'::text; ?column? -- t (1 row) links=# Cheers, Alex Gossamer Threads Inc. -- Alex KrohnEmail: [EMAIL PROTECTED] Internet Consultant Phone: (604) 687-5804 http://www.gossamer-threads.com Fax : (604) 687-5806
Re: [BUGS] select fails on indexed varchars.
Hi Tom, > > [postgres@penguin pgsql]$ locale > > LANG=en_US > > LC_CTYPE="en_US" > > LC_NUMERIC="en_US" > > LC_TIME="en_US" > > LC_COLLATE="en_US" > > LC_MONETARY="en_US" > > LC_MESSAGES="en_US" > > LC_ALL=en_US > > [postgres@penguin pgsql]$ > > > Postmaster is running as user pgsql. Any ideas on workarounds? > > Use locale "C" unless you have a really good reason why you need > en_US sorting order. > > Beware of changing the postmaster's locale on the fly, however, > since that will leave you with corrupted (out-of-order) indexes. > Safest to dump/initdb in new locale/reload. How would I go about changing that? Setting LANG and LC_ALL in the pgsql users home directory .bashrc? Or do I need to edit the startup file? Cheers, Alex
Re: [BUGS] select fails on indexed varchars.
Hi Tom,
> >> So it does. Okay, what was the complete test case again?
> >> I'm afraid I didn't save your original message because I wrote it off
> >> as a known problem ...
>
> > Here it is:
>
> > links=# create table foo ( a char(25) );
> > CREATE
> > links=# create index foodx on foo (a);
> > CREATE
> > links=# insert into foo values ('Test/Test');
> > INSERT 29689 1
> > links=# select * from foo;
> > a
> > ---
> > Test/Test
> > (1 row)
>
> > links=# select * from foo where a like 'Test/%';
> > a
> > ---
> > (0 rows)
>
> How odd. I get 'Test/Test' from the last select, under both 7.0.2
> and current sources, when using C locale. The query certainly looks
> like the kind that would suffer from the LIKE-optimization problem in
> non-C locales ... but we seem to have established that you've gotten
> the postmaster switched into C locale.
>
> What does EXPLAIN VERBOSE select * from foo where a like 'Test/%';
> show?
Here's a cut and paste, not sure if there is a nicer way to output it:
links=# EXPLAIN VERBOSE select * from foo where a like 'Test/%';
NOTICE: QUERY DUMP:
{ INDEXSCAN :startup_cost 0.00 :total_cost 8.14 :rows 10 :width 12 :state <>
:qptargetlist ({ TARGETENTRY :resdom { RESDOM :resno 1 :restype 1042 :restypmod 29
:resname a :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR
:varno 1 :varattno 1 :vartype 1042 :vartypmod 29 :varlevelsup 0 :varnoold 1
:varoattno 1}}) :qpqual ({ EXPR :typeOid 16 :opType op :oper { OPER :opno 1211 :opid
850 :opresulttype 16 } :args ({ VAR :varno 1 :varattno 1 :vartype 1042 :vartypmod 29
:varlevelsup 0 :varnoold 1 :varoattno 1} { CONST :consttype 25 :constlen -1
:constisnull false :constvalue 10 [ 10 0 0 0 84 101 115 116 47 37 ] :constbyval
false })}) :lefttree <> :righttree <> :extprm () :locprm () :initplan <> :nprm 0
:scanrelid 1 :indxid ( 18825) :indxqual (({ EXPR :typeOid 16 :opType op :oper { OPER
:opno 1061 :opid 1052 :opresulttype 16 } :args ({ VAR :varno 1 :varattno 1 :vartype
1042 :vartypmod 29 :varlevelsup 0 :varnoold 1 :varoattno 1} { CONST :consttype 1042
:con!
stlen -1 :constisnull false :constvalue 9 [ 9 0 0 0 84 101 115 116 47 ] :constbyval
false })} { EXPR :typeOid 16 :opType op :oper { OPER :opno 1058 :opid 1049
:opresulttype 16 } :args ({ VAR :varno 1 :varattno 1 :vartype 1042 :vartypmod 29
:varlevelsup 0 :varnoold 1 :varoattno 1} { CONST :consttype 1042 :constlen -1
:constisnull false :constvalue 9 [ 9 0 0 0 84 101 115 116 48 ] :constbyval false
})})) :indxqualorig (({ EXPR :typeOid 16 :opType op :oper { OPER :opno 1061 :opid
1052 :opresulttype 16 } :args ({ VAR :varno 1 :varattno 1 :vartype 1042 :vartypmod 29
:varlevelsup 0 :varnoold 1 :varoattno 1} { CONST :consttype 1042 :constlen -1
:constisnull false :constvalue 9 [ 9 0 0 0 84 101 115 116 47 ] :constbyval false })}
{ EXPR :typeOid 16 :opType op :oper { OPER :opno 1058 :opid 1049 :opresulttype 16 }
:args ({ VAR :varno 1 :varattno 1 :vartype 1042 :vartypmod 29 :varlevelsup 0
:varnoold 1 :varoattno 1} { CONST :consttype 1042 :constlen -1 :constisnull false :con!
stvalue 9 [ 9 0 0 0 84 101 115 116 48 ] :constbyval false })})) :ind
NOTICE: QUERY PLAN:
Index Scan using foodx on foo (cost=0.00..8.14 rows=10 width=12)
EXPLAIN
links=#
Cheers,
Alex
Re: [BUGS] select fails on indexed varchars.
Hi Tom,
> Alex Krohn <[EMAIL PROTECTED]> writes:
> >> On my machine, these produce 't' in C locale, but 'f' in en_US locale.
>
> > Seem to be in C locale:
>
> So it does. Okay, what was the complete test case again?
> I'm afraid I didn't save your original message because I wrote it off
> as a known problem ...
Here it is:
links=# create table foo ( a char(25) );
CREATE
links=# create index foodx on foo (a);
CREATE
links=# insert into foo values ('Test/Test');
INSERT 29689 1
links=# select * from foo;
a
---
Test/Test
(1 row)
links=# select * from foo where a like 'Test/%';
a
---
(0 rows)
Cheers,
Alex
Re: [BUGS] select fails on indexed varchars.
Hi Tom,
> >> What does EXPLAIN VERBOSE select * from foo where a like 'Test/%';
> >> show?
>
> Well, the indexqual is just what it should be for C locale:
>
> :indxqual ((
> { EXPR :typeOid 16 :opType op :oper
> { OPER :opno 1061 :opid 1052 :opresulttype 16 } :args (
> { VAR :varno 1 :varattno 1 :vartype 1042 :vartypmod 29 :varlevelsup 0 :varnoold 1
>:varoattno 1}
> { CONST :consttype 1042 :constlen -1 :constisnull false :constvalue 9 [ 9 0 0 0 84
>101 115 116 47 ] :constbyval false })}
> { EXPR :typeOid 16 :opType op :oper
> { OPER :opno 1058 :opid 1049 :opresulttype 16 } :args (
> { VAR :varno 1 :varattno 1 :vartype 1042 :vartypmod 29 :varlevelsup 0 :varnoold 1
>:varoattno 1}
> { CONST :consttype 1042 :constlen -1 :constisnull false :constvalue 9 [
> 9 0 0 0 84 101 115 116 48 ] :constbyval false })}))
>
> This mess translates as
>
> a >= 'Test/'::bpchar AND a < 'Test0'::bpchar
>
> which is what the LIKE index optimizer is supposed to generate.
> I infer that one or the other of these conditions yields false on your
> machine, which should not be happening if the thing is in C locale.
Here's what I get:
links=# select * from foo where a >= 'Test/'::bpchar;
a
---
Test/Test
(1 row)
links=# select * from foo where a < 'Test0'::bpchar;
a
---
(0 rows)
links=#
Are you saying the second test should have returned true under C locale?
Is this a version dependant bug? Will downgrading to 6.x get me going?
Cheers,
Alex
[BUGS] LIBPQ: program crashed during executing query
Hi! My C program executes a pretty complex query (of length about 600 chars, with subqueries, etc.). When I run it (on Linux), it crashes with "Segmentation fault (core dumped)". I'm sure that the program crashes on this specific PQexec command. Is there a length limit for queries in PQexec, or is there any other reason for it? The query is attached. Thanks in advance, Alex P.S. The query is: SELECT s1.GivingCode FROM Scored s1, Scored s2 WHERE s1.Score >= 8 AND s2.Score >= 8 AND s1.Year = s2.Year AND s1.GivingCode = s2.ReceivingCode AND s1.ReceivingCode = s2.GivingCode AND s1.GivingCode NOT IN (SELECT Code FROM Friends) AND s1.ReceivingCode IN (SELECT Code FROM Friends) AND NOT EXISTS (SELECT * FROM Represented re1, Represented re2, Scored sc WHERE re1.Year = re2.Year AND re1.Year = sc.Year AND re1.Code = s1.GivingCode AND re2.Code = s1.ReceivingCode AND ((sc.GivingCode = s1.ReceivingCode AND sc.ReceivingCode = s1.GivingCode AND sc.Score < 8) OR (sc.GivingCode = s1.GivingCode AND sc.ReceivingCode = s1.ReceivingCode AND sc.Score < 8))) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] LIBPQ: program crashed during executing query
Please, ignore my question. The problem was that I did PQclear(res) before calling to PQgetvalue(res,...) Anyway, it should not crush (IMHO). Alex "Alex Glikson" <[EMAIL PROTECTED]> wrote in message a1jjj5$tas$[EMAIL PROTECTED]">news:a1jjj5$tas$[EMAIL PROTECTED]... > Hi! > > My C program executes a pretty complex query (of length about 600 chars, > with subqueries, etc.). > When I run it (on Linux), it crashes with "Segmentation fault (core > dumped)". > I'm sure that the program crashes on this specific PQexec command. > > Is there a length limit for queries in PQexec, or is there any other reason > for it? > The query is attached. > > Thanks in advance, > > Alex > > P.S. The query is: > SELECT s1.GivingCode FROM Scored s1, Scored s2 > WHERE s1.Score >= 8 AND s2.Score >= 8 AND s1.Year = s2.Year AND >s1.GivingCode = s2.ReceivingCode AND s1.ReceivingCode = s2.GivingCode AND >s1.GivingCode NOT IN (SELECT Code FROM Friends) AND >s1.ReceivingCode IN (SELECT Code FROM Friends) AND >NOT EXISTS (SELECT * FROM Represented re1, Represented re2, Scored sc > WHERE > re1.Year = re2.Year AND re1.Year = sc.Year AND re1.Code = s1.GivingCode > AND > re2.Code = s1.ReceivingCode AND > ((sc.GivingCode = s1.ReceivingCode AND sc.ReceivingCode = s1.GivingCode > AND sc.Score < 8) OR > (sc.GivingCode = s1.GivingCode AND sc.ReceivingCode = s1.ReceivingCode > AND sc.Score < 8))) > > > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #2451: Short column names return no values within function
The following bug has been logged online:
Bug reference: 2451
Logged by: Alex Weslowski
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Windows XP
Description:Short column names return no values within function
Details:
Below is code for duplicating this error. Fields "Peg" and "Rs03" and "Rs12"
are absent from returned record (either Record or Cursor) even though the
values in the table are not null.
Problem might be related to type conversion (NULL converts to '' which has
no meaning to INT or NUMERIC).
Problem is fixed by renaming columns to "Peg_Ratio" and "RS03RS" and
"RS12RS". So, there is something more going on here, related to length of
column name.
-
CREATE TABLE TestBug (
Date DATE,
Symbol VARCHAR(10),
Peg NUMERIC(8, 3),
RS03 SMALLINT,
RS12 SMALLINT
);
INSERT INTO TestBug VALUES ('5/18/06', 'ABAX', 1.38, 78, 95);
INSERT INTO TestBug VALUES ('5/18/06', 'IRIX', NULL, 97, 92);
INSERT INTO TestBug VALUES ('5/18/06', 'SCSC', 1.31, 59, 65);
CREATE TYPE row_TestBug AS (
idx INT,
str VARCHAR(512)
);
CREATE OR REPLACE FUNCTION fn_TestBug(
d DATE
)
RETURNS SETOF row_TestBug AS $$
DECLARE
varSym VARCHAR(10) := '';
peg VARCHAR(5) := '';
numPeg NUMERIC(8, 3) := NULL;
varPeg VARCHAR(9) := NULL;
rs03 VARCHAR(3) := '';
intRs03 INT := NULL;
varRs03 VARCHAR(8) := NULL;
rs12 VARCHAR(3) := '';
intRs12 INT := NULL;
varRs12 VARCHAR(8) := NULL;
str VARCHAR(512) := '';
i INT := 0;
rtn row_TestBug;
rec RECORD;
BEGIN
FOR rec IN SELECT Symbol, RS03, RS12, Peg
FROM TestBug WHERE Date=d
ORDER BY RS12 DESC LOOP
varSym := rec.Symbol;
varSym := RTRIM(varSym) || REPEAT(' ', 8 - LENGTH(RTRIM(varSym)));
rs03 := ' NA';
IF (rec.RS03 IS NOT NULL) THEN
IF (rec.RS03 > 0) THEN
rs03 := CAST(rec.RS03 AS VARCHAR);
END IF;
END IF;
rs12 := ' NA';
IF (rec.RS12 IS NOT NULL) THEN
IF (rec.RS12 > 0) THEN
rs12 := CAST(rec.RS12 AS VARCHAR);
END IF;
END IF;
peg := ' NA';
IF (rec.Peg IS NOT NULL) THEN
peg := CAST(CAST(rec.Peg AS NUMERIC(5, 2)) AS VARCHAR);
END IF;
str := varSym || ' 3-Mo RS:' || rs03 || ' 12-Mo RS:' || rs12 || '
PEG: '
|| peg;
rtn := ROW(i, str);
RETURN NEXT rtn;
i := i + 1;
END LOOP;
RETURN;
END;
$$ LANGUAGE plpgsql;
SELECT str FROM fn_TestBug('2006/05/18');
---(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
[BUGS] BUG #2510: ERROR: out of memory DETAIL: Failed on request of size 825242672.
The following bug has been logged online: Bug reference: 2510 Logged by: alex tsai Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4 Operating system: FreeBSD 6.1 stable Description:ERROR: out of memory DETAIL: Failed on request of size 825242672. Details: I'm having a trouble trying to insert a tuple. I'm getting this kind of error "ERROR: out of memory DETAIL: Failed on request of size 825242672". What could it be? the table i'm working with has already 4629138 tuples. When i terminate my program and start it again everything work fine for another couple of minutes and then i'm get the same error. CONTEXT: SQL statement "INSERT INTO billing.calls(id_ats, btime, etime, tt, ts, indexa, phonea, indexb, phoneb, cc, value, restart) VALUES ( $1 , $2 , $3 , $4 , $5 , $6 , $7 , $8 , $9 , $10 , $11 , $12 )" Sincerely, Alex Tsai. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #2580: Analyze table cause invalid memory alloc error in "start with xx" select statement
The following bug has been logged online: Bug reference: 2580 Logged by: Alex Zhang Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4-1 Operating system: Windows XP sp2 and Windows 2003 Server Description:Analyze table cause invalid memory alloc error in "start with xx" select statement Details: When installing postgresql with China-PRC locale and UTF8 Encoding, it causes the following problem: After running "analyze", or "vacuum with analyze" commands on a table or database, select statements with "like 'a%'" kind of clause report "invalid memory alloc request size" error 2147483648" and yields no results. There is 43 rows in my table and it worked fine before with mysql. I have exported a database dump that can reliably recreate this problem. I can send it if you give me an email address. Just restore the data (with some foreign key errors that can be ignored) and run select * from element where name like 'a%'; you get 0 records, which is correct. then run analyze element; select * from element where name like 'a%'; you get: ERROR: invalid memory alloc request size 2147483648. Note that this error does not occur if I install the postgresql with locale set to "C". I can also avoid this problem by setting the particular database encoding to EUC_CN (when installed with China-PRC locale). ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #2778: make check failed
The following bug has been logged online:
Bug reference: 2778
Logged by: Alex Deiter
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: Solaris 9 sparc
Description:make check failed
Details:
System detail:
Solaris 9 sparc, gcc 4.0.2, 4.1.1:
$ ./configure --enable-thread-safety --disable-nls --without-perl
--without-python --without-krb5 --without-openssl --without-readline
...
$ make && make check
...
===
1 of 98 tests failed.
===
The differences that caused some tests to fail can be viewed in the
file `./regression.diffs'. A copy of the test summary that you see
above is saved in the file `./regression.out'.
$ less src/test/regress/regression.diffs
*** ./expected/errors.out Sat Feb 12 01:15:11 2005
--- ./results/errors.outThu Nov 23 18:14:08 2006
***
*** 300,308
select 1/0::int8;
ERROR: division by zero
select 1::int2/0;
! ERROR: division by zero
select 1/0::int2;
! ERROR: division by zero
select 1::numeric/0;
ERROR: division by zero
select 1/0::numeric;
--- 300,310
select 1/0::int8;
ERROR: division by zero
select 1::int2/0;
! ERROR: floating-point exception
! DETAIL: An invalid floating-point operation was signaled. This probably
means
an out-of-range result or an invalid operation, such as division by zero.
select 1/0::int2;
! ERROR: floating-point exception
! DETAIL: An invalid floating-point operation was signaled. This probably
means
an out-of-range result or an invalid operation, such as division by zero.
select 1::numeric/0;
ERROR: division by zero
select 1/0::numeric;
==
i found cause of this error:
#include
int testdiv(int i, long k) {
if (k == 0) printf("found divide by zero\n");
return(i/k);
}
int main() {
int i = testdiv(1,0);
return(i);
}
when compile it without optimization, it works fine:
$ gcc t.c
$ ./a.out
found divide by zero
Arithmetic Exception (core dumped)
but optimization break it:
$ gcc -O3 t.c
$ ./a.out
Arithmetic Exception (core dumped)
Thanks a lot!
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2812: Transaction is aborted after error
The following bug has been logged online: Bug reference: 2812 Logged by: Alex Piyevsky Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1 Operating system: Linux Kernel-2.4.21-glibc-2.3.2 x86 32bit Description:Transaction is aborted after error Details: We issue a command which drops the existing table and recreates the table under the same name, all in one transaction. If the table does not previously exist, an error message is returned for the drop command and the transaction aborts with the following: current transaction is aborted, commands ignored until end of transaction block please advise ---(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 #3973: pg_dump using inherited tables do not always restore
The following bug has been logged online: Bug reference: 3973 Logged by: Alex Hunsaker Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.0 Operating system: Linux Description:pg_dump using inherited tables do not always restore Details: create table junk (val integer not null, val2 integer); create table junk_child () inherits (junk_1); alter table junk_child alter column val drop not null; insert into junk_child (val2) values (1); pg_dump -t junk -t junk_child pg_restore/psql will fail because junk_child.val now has a not null constraint ---(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
Re: [BUGS] BUG #3973: pg_dump using inherited tables do not always restore
On Wed, Feb 20, 2008 at 3:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Alex Hunsaker" <[EMAIL PROTECTED]> writes: > > create table junk (val integer not null, val2 integer); > > create table junk_child () inherits (junk_1); > > alter table junk_child alter column val drop not null; > > insert into junk_child (val2) values (1); > > > pg_dump -t junk -t junk_child > > > pg_restore/psql will fail because junk_child.val now has a not null > > constraint > > Actually the bug is that ALTER TABLE allows you to do that. It should > not be possible to drop an inherited constraint, but right now there's > not enough information in the system catalogs to detect the situation. > Fixing this has been on the TODO list for awhile: > > o %Prevent child tables from altering or dropping constraints > like CHECK that were inherited from the parent table > > regards, tom lane > Hrm how about something like the attached patch? It only handles set not null/drop not null. And I thought about making it so set default behaved the same way, but i can see how that can be useful in the real world. Thoughts? Arguably pg_dump should just do something similar to what it does for set default (because that dumps correctly)... I only say that because there specific regressions test for the behavior I outlined above. Which is now "broken" with my patch. Be gentle... its my first dive into postgresql guts... inhertied_null.patch Description: Binary data -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [PATCHES] [BUGS] BUG #3973: pg_dump using inherited tables do not always restore
> It seems much more restrictive than necessary, plus it does nothing > for the check-constraint case. My recollection of the previous > discussion about how to fix this was that we needed to add an inhcount > column to pg_constraint, and add entries for not-null constraints (at > least inherited ones) to pg_constraint so that they'd be able to have > inhcount fields. The latter would also allow us to attach names to > not-null constraints, which I think is required by spec but we've never > supported. > > regards, tom lane > Ok I found some time to look at what would be involved in that... Seems doable. Ill see what I can whip up in the next month. (Im time pressed, who isn't though) Ill just post whatever i come up with (if and when) to psql-patches. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
[BUGS] 8.3.0 backend segfaults
(Sorry if duplicates show up this is the third time ive posted this in
the past 10 hours, Im assuming it got dropped because of the
attachments)
Problem: Apparently random segfaults apparently query agnostic, seem
to be more frequent when a pg_dump is running
The most frequent query it segfaults with is:
select w.worker_id, w.worker_id as printerid, w.worker, w.alias,
coalesce(w.alias, w.worker) as name, w.active, w.last_active,
w.last_deactive, round(extract(epoch from now()) - extract(epoch from
w.last_deactive)) as time_off from workers as w left join worker_vis
as wv on wv.worker_id = w.worker_id and wv.defunct = 0 and (
((wv.auth_id = ?) and (wv.auth_class = data_class('user_id'))) or
((wv.auth_id = ?) and (wv.auth_class = data_class('clinic_id'
where wv.worker_vis_id is not null and w.defunct = 0 order by
coalesce(w.alias, w.worker);
(sample arguments, they do not seem to make a difference)
167214, 13
167340, 16
But have seen other simpler queries such as (sorry no backtraces for
these... yet)
insert into audit_transaction (action, open_user_id, page_load_id,
user_id) values (?, ?, ?, ?); ARGS=suds, 509057, 15148365, 167217
If I select * from workers; and select * from workers_active;
everything looks good, no segfaults. I can also take a pg_dump if
virtually nothing is using the database. Otherwise pg_dump dies
randomly with an errors like:
Dumping the contents of table "clients_audit" failed: PQgetCopyData() failed.
Dumping the contents of table "file_data" failed: PQgetCopyData() failed.
Dumping the contents of table "workers_audit" failed: PQgetCopyData() failed.
(note these are probably 3 of the larger tables in the database, maybe
it has something to do with statement_timeout, i do have it set quite
low (3 min) ?)
If I manually prepare and execute the above queries they work fine.
prepare worker (bigint, bigint) as select w.worker_id, w.worker_id as
printerid, w.worker, w.alias, coalesce(w.alias, w.worker) as name,
w.active, w.last_active, w.last_deactive, round(extract(epoch from
now()) - extract(epoch from w.last_deactive)) as time_off from workers
as w left join worker_vis as wv on wv.worker_id = w.worker_id and
wv.defunct = 0 and ( ((wv.auth_id = ?) and (wv.auth_class =
data_class('user_id'))) or ((wv.auth_id = ?) and (wv.auth_class =
data_class('clinic_id' where wv.worker_vis_id is not null and
w.defunct = 0 order by coalesce(w.alias, w.worker);
execute worker (167214, 13);
Core dumps and binaries available if needed. I have about 6 core dumps
across 2 different servers. Which leads me to believe its either
postgres bug or a corrupt database (the other server is a pitr slave
for the master which i switched over to see if i could reproduce the
segfault on the master)
Nothing in dmesg, nothing in mcelog.
Raid controller is a 3ware 9550SX-12 with 6 70GB WD Raptor hard drives
in a raid 10, smart tests pass fine... everything looks good.
Work load is a web application where each page beings a transaction;
creates a temp table, does a few selects, inserts and updates and the
commits.
Postgresql 8.2.5 was working without any problems just prior to the upgrade.
\d workers
Table "public.workers"
Column | Type |
Modifiers
---+--+-
worker_id | bigint | not null default
nextval('workers_worker_id_seq'::regclass)
date_created | timestamp with time zone | not null default now()
clientid | bigint | not null
worker| text | not null
alias | text |
job_type | smallint | not null
active| smallint | not null default 0
last_active | timestamp with time zone |
last_deactive | timestamp with time zone |
defunct | smallint | not null default 0
audit_class | integer |
audit_date| timestamp with time zone | not null default now()
audit_desc| text |
audit_id | bigint |
audit_seq | integer | not null default
nextval('audit_basic_audit_seq_seq'::regclass)
audit_table | character varying(64)|
audit_tid | bigint |
audit_type| character varying(32)|
audit_orig_id | integer |
path | text |
Indexes:
"workers_pkey" PRIMARY KEY, btree (worker_id) CLUSTER
Triggers:
workers_audit_aud BEFORE INSERT OR DELETE OR UPDATE ON workers FOR
EACH ROW EXECUTE PROCEDURE audit_table_go()
\d worker_vis
Table "public.worker_vis"
Column | Type |
Modifiers
---+--+---
Re: [BUGS] 8.3.0 backend segfaults
On Tue, Mar 11, 2008 at 10:59 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Alex Hunsaker" <[EMAIL PROTECTED]> writes: > > Problem: Apparently random segfaults apparently query agnostic, seem > > to be more frequent when a pg_dump is running > > Hmm, seems from the backtrace that we're trying to do a replan with an > invalid ActiveSnapshot. What sequence of operations is the connected > client performing, exactly? (I'm not worried about the details of the > SQL per se, but of how it's preparing/issuing queries.) > > regards, tom lane > Its through perl-dbi using ->prepare, ->execute.. is that what you mean? Also this is with mod_perl and Apache::DBI. So a typical transacion looks like connect to postgres; begin; do stuff here; commit or rollback; (next page load) begin; so potentially a database connection/session is reused on the next page load if that makes a difference. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 8.3.0 backend segfaults
FYI right now Im trying: Author: tgl Date: Sat Feb 2 22:26:17 2008 + Fix WaitOnLock() to ensure that the process's "waiting" flag is reset after erroring out of a wait. We can use a PG_TRY block for this, but add a comment explaining why it'd be a bad idea to use it for any other state cleanup. Back-patch to 8.2. Prior releases had the same issue, but only with respect to the process title, which is likely to get reset almost immediately anyway after the transaction aborts, so it seems not worth changing them. In 8.2 and HEAD, the pg_stat_activity "waiting" flag could remain set incorrectly for a long time. Which was just after 8.3 was stamped. Ill see if anything happens tomorrow when the masses start using it again. I will also try to find a way to reproduce it. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 8.3.0 backend segfaults
Oops we actually use DBI->prepare_cached() not DBI->prepare() which to my understanding should be roughly equivalent to (because of Apache::DBI): prepare query ; begin; execute query; commit; (next page load) begin; execute query; commit; I can turn that off and only use DBI->prepare() as a test. Or heck just cut DBI->prepare() out and just quote everything and send them through using DBI->do() instead. That is if you think that could be the culprit. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 8.3.0 backend segfaults
On Wed, Mar 12, 2008 at 12:19 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > Now personally, I am much more interested in *reproducing* the problem > than merely dodging it. I can understand if you just need a workaround > yesterday, but please see if you can get a reproducible test case ... > > regards, tom lane > Yesterday would be nice ;). Ill keep trying to get a test case. In the mean time here is a new backtrace I just got (lord knows how... it seems to be as soon as I stop trying to make it crash and look away, thats when it does). This is 2 commits ( the one i reference in my later email) after 8.3 was stamped. Happens to be the same query as before... Core was generated by `postgres: docsysweb CaduRx 192.168.134.1(54493) BIND '. Program terminated with signal 11, Segmentation fault. #0 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x0045a55e in heapgettup (scan=0xbd8bd0, dir=, nkeys=0, key=0x0) at heapam.c:431 #2 0x0045a96d in heap_getnext (scan=0xbd8bd0, direction=14717080) at heapam.c:1259 #3 0x00525478 in SeqNext (node=) at nodeSeqscan.c:92 #4 0x0051a74f in ExecScan (node=0xbd7ed0, accessMtd=0x5253c0 ) at execScan.c:103 #5 0x00514380 in ExecProcNode (node=0xbd7ed0) at execProcnode.c:334 #6 0x005135ba in ExecutorRun (queryDesc=, direction=ForwardScanDirection, count=1) at execMain.c:1233 #7 0x0051c82d in postquel_getnext (es=0xe09038, fcache=0xd0e4c0) at functions.c:378 #8 0x0051ce6d in fmgr_sql (fcinfo=0x7fffe6d7af90) at functions.c:479 #9 0x005163bd in ExecMakeFunctionResult (fcache=0xd0df50, econtext=0xd0e3e0, isNull=0x7fffe6d7b3df "", isDone=0x0) at execQual.c:1351 #10 0x005190ba in ExecEvalExprSwitchContext (expression=0x2ae1c608c658, econtext=0xe09098, isNull=0x32d , isDone=0x0) at execQual.c:3726 #11 0x00568d4d in evaluate_expr (expr=, result_type=23, result_typmod=-1) at clauses.c:3273 #12 0x005699b1 in simplify_function (funcid=2214548, result_type=23, result_typmod=-1, args=0xcfbfa0, allow_inline=1 '\001', context=0x7fffe6d7b530) at clauses.c:2887 #13 0x0056a1ca in eval_const_expressions_mutator (node=0xc34170, context=0x7fffe6d7b530) at clauses.c:1795 #14 0x0056ae15 in estimate_expression_value (root=, node=0x2ae1c608c658) at clauses.c:1719 #15 0x005f8906 in get_restriction_variable (root=0xc32160, args=, varRelid=0, vardata=0x7fffe6d7b640, other=0x7fffe6d7b678, varonleft=0x7fffe6d7b68f "\001\236") at selfuncs.c:3570 #16 0x005fa2e2 in eqsel (fcinfo=) at selfuncs.c:169 #17 0x00644f4c in OidFunctionCall4 (functionId=, arg1=12788064, arg2=532, arg3=12796016, arg4=0) at fmgr.c:1615 #18 0x0056cd52 in restriction_selectivity (root=0xc32160, operator=532, args=0xc34070, varRelid=0) at plancat.c:805 #19 0x0054e447 in clause_selectivity (root=0xc32160, clause=0xc341c0, varRelid=0, jointype=JOIN_INNER) at clausesel.c:639 #20 0x0054dd8f in clauselist_selectivity (root=0xc32160, clauses=, varRelid=0, jointype=JOIN_INNER) at clausesel.c:123 #21 0x0054e0f8 in clause_selectivity (root=0xc32160, clause=0xcf9f80, varRelid=0, jointype=JOIN_INNER) at clausesel.c:576 #22 0x0054e3da in clause_selectivity (root=0xc32160, clause=, varRelid=0, jointype=JOIN_INNER) at clausesel.c:597 #23 0x0054dd8f in clauselist_selectivity (root=0xc32160, clauses=, varRelid=0, jointype=JOIN_INNER) at clausesel.c:123 #24 0x0054f64f in set_baserel_size_estimates (root=0x2ae1c608c658, rel=0xc35b28) at costsize.c:2262 #25 0x0054d32c in set_rel_pathlist (root=0xc32160, rel=0xc35b28, rti=2, rte=0xc1d110) at allpaths.c:215 #26 0x0054dbb2 in make_one_rel (root=0xc32160, joinlist=0xc35a48) at allpaths.c:150 #27 0x0055f3a0 in query_planner (root=0xc32160, tlist=, tuple_fraction=0, limit_tuples=-1, cheapest_path=0x7fffe6d7c050, sorted_path=0x7fffe6d7c048, num_groups=0x7fffe6d7c058) at planmain.c:249 #28 0x0055fcd1 in grouping_planner (root=0xc32160, tuple_fraction=) at planner.c:897 #29 0x00560d48 in subquery_planner (glob=0xe19b20, parse=0xe19bb0, level=0, tuple_fraction=0, subroot=0x7fffe6d7c218) at planner.c:431 #30 0x00561141 in standard_planner (parse=0xe19bb0, cursorOptions=0, boundParams=0x0) at planner.c:158 #31 0x005a1971 in pg_plan_query (querytree=0xe19bb0, cursorOptions=0, boundParams=0x0) at postgres.c:681 #32 0x005a1a23 in pg_plan_queries (querytrees=, cursorOptions=0, boundParams=0x0, needSnapshot=0 '\0') at postgres.c:752 #33 0x00633cf3 in do_planning (querytrees=0xc32130, cursorOptions=0) at plancache.c:560 #34 0x006340cb in RevalidateCachedPlan (plansource=0xb58460, useResOwner=0 '\0') at plancache.c:484 #35 0x005a3815 in PostgresMain (argc=4, argv=, username=0x8f32f0 "docsysweb") at postgres.c:1605 #36 0x00579a1f in ServerLoop () at postmaster.c:3207 #37 0x0
Re: [BUGS] 8.3.0 backend segfaults
On Wed, Mar 12, 2008 at 12:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Alex Hunsaker" <[EMAIL PROTECTED]> writes: > > > the mean time here is a new backtrace I just got (lord knows how... it > > seems to be as soon as I stop trying to make it crash and look away, > > thats when it does). > > Not sure that you are clear on what's happening here, but the train of > events is something like > - you prepare a statement > - somebody modifies the schema of one of the tables used in the > statement > - you try to execute the statement, and updating the prepared > plan crashes > > If you say "none of my stuff is changing any schemas", then I'd guess > that the triggering event is a background autovacuum, which forces > replan just like an intentional schema change would. Does stopping > autovacuum make the problem go away? Yep turning off autovacuum seems to have fixed it. And once I manually vacuum analyze workers; it blows up almost instantly. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 8.3.0 backend segfaults
On Wed, Mar 12, 2008 at 9:22 AM, Greg Sabino Mullane <[EMAIL PROTECTED]> wrote: ommits. > > Are you sure you are calling DBI->connect *after* the Apache children > are created? Yes. Major problems like this can happen if not. The use of > prepare_cached() may be adding to the problem as well, especially if > you are using temp tables. The tables its failing on happen to not be temp tables (I only have 1 temp table and only do 1 insert into it for the entire transaction). >In DBD::Pg, prepared statements are not > actually prepared (in most cases) until just before the first execute, > to account for late bindings and to be more efficient. Some related > DBD::Pg attribs to look at are pg_server_prepare and pg_prepare_now. Hrm, well i dont ever prepare them in mass, I only prepare them and when im going to be calling execute right afterwords. But ill try turning on autovac and setting pg_prepare_now to 1 and see what happens. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 8.3.0 backend segfaults
On Wed, Mar 12, 2008 at 9:49 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> > On Wed, Mar 12, 2008 at 12:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> >> If you say "none of my stuff is changing any schemas", then I'd guess
> >> that the triggering event is a background autovacuum, which forces
> >> replan just like an intentional schema change would. Does stopping
> >> autovacuum make the problem go away?
>
> > Yep turning off autovacuum seems to have fixed it. And once I
> > manually vacuum analyze workers; it blows up almost instantly.
>
> Yeah, I was going to suggest that you ought to be able to extract
> a test case involving doing a manual vacuum in between prepare and
> execute. I suspect it wouldn't even need to involve more than one
> session.
Here is what im trying right now with no success:
3 clients doing this:
while(1)
{
$db->begin_work();
my $sth = $db->prepare_cached('select * from junk left join
junk as j on j.junk = junk.junk where junk.junk like ? limit 1;');
print "VAC!\n";
sleep 10;
print "EX!\n";
$sth->execute('junk') || die "failed: $!";
$sth->fetchall_arrayref();
$db->commit();
$db->{'AutoCommit'} = 0;
$db->{'AutoCommit'} = 1;
}
where when it prints VAC I :
update junk set junk = 'junkab';
VACUUM ANALYZE verbose junk;
(also tried deleting, and inserting a bunch of junk...)
3 other clients doing:
while(1)
{
$db->begin_work();
my $sth = $db->prepare_cached('select * from junk left join
junk as j on j.junk = junk.junk where junk.junk like ? limit 1;');
$sth->execute('junk') || die "failed: $!";
$sth->fetchall_arrayref();
$db->rollback();
}
\d junk
Table "public.junk"
Column | Type | Modifiers
+--+---
junk | text |
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 8.3.0 backend segfaults
On Wed, Mar 12, 2008 at 10:31 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>
> > Here is what im trying right now with no success:
>
>
> > my $sth = $db->prepare_cached('select * from junk left join
> > junk as j on j.junk = junk.junk where junk.junk like ? limit 1;');
>
> You need to duplicate more of the original query structure to provoke
> the problem, likely. The crash appeared to involve evaluation of an
> immutable SQL function ...
Will do.
Just for the record its defined as
create or replace function data_class(text) returns integer as 'select
data_class from data_classes where data_id = $1 and defunct = 0'
language 'sql' stable strict;
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
