[BUGS] BUG #4758: deadlock.c:944
The following bug has been logged online: Bug reference: 4758 Logged by: sergey Email address: op...@ydk.com.ua PostgreSQL version: 8.4beta1 Operating system: Linux 2.6.25-gentoo-r8 Description:deadlock.c:944 Details: i have table with 15 records Table "public.test" Column | Type | Modifiers +-+--- y | integer | then i run 3 followng commands in parralel: ./bin/psql billy < sql.sql in file sql.sql only 1 statements "UPDATE test SET y=1;" and what i see in log: ERROR: 40P01: deadlock detected DETAIL: Process 10237 waits for ShareLock on transaction 165664; blocked by process 10242. Process 10242 waits for ShareLock on transaction 165691; blocked by process 10237. Process 10237: UPDATE test SET y=1; Process 10242: UPDATE test SET y=1; HINT: See server log for query details. LOCATION: DeadLockReport, deadlock.c:944 approximately one message per second -- 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 #2862: ERROR: failed to build any 7-way joins
The following bug has been logged online: Bug reference: 2862 Logged by: Sergey Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.0-1 Operating system: Windows XP Pro SP2 Description:ERROR: failed to build any 7-way joins Details: After migrating to 8.2 I received an error: ERROR: failed to build any 7-way joins SQL state: XX000 STATEMENT: select * from v_well_main w LEFT OUTER JOIN v_state_main s ON (w."Id_well"=s."Id_wl") LEFT OUTER JOIN v_expl_main e ON (w."Id_well"=e."Id_wl") where w."Id_dep"=7 View v_well_main contained statement: SELECT w."Id_well", w."Name_wl", w."Num", w."Cod", c."Name" AS "Categor_name", w."Inv_num", w."Balance", w."Obl", w."Reg", w."Sl_rada", w."Latitude_deg", w."Latitude_min", w."Latitude_sec", w."Longitude_deg", w."Longitude_min", w."Longitude_sec", w."Topograf_note", w."Passp_org", w."Passp_date", w."Executor", w."Exec_phone", w."Director", w."Al_rotor", w."Al_gr", w."dP", o."Id_org", o."Name", o."Address", o."EDRPOU", o."Phone", b."Name" AS name_obl, b."KOATUU" AS obl_koatuu, r."Name" AS name_raj, r."KOATUU" AS raj_koatuu, s."Name" AS sl, v."Id_dep", v."Name_dep", v."Typ", v.obj_typ, v."Begin", v."End" FROM v_well_obj v, "Categor_dic" c, "Well" w LEFT JOIN "Obl_dic" b ON w."Obl" = b."Id_obl" LEFT JOIN "Raj_dic" r ON w."Reg" = r."Id_raj" LEFT JOIN "Sl_rad_dic" s ON w."Sl_rada" = s."Id_s" LEFT JOIN "Org_dic" o ON w."Passp_org" = o."Id_org" WHERE v."Id_well" = w."Id_well" AND c."Id_cat" = w."Categor" ORDER BY w."Num"; The query was executed in pgAdmin III If STATEMENT change to: select * from v_well_main w where w."Id_dep"=113 then it executed OK ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #3820: auto-installer-failed
The following bug has been logged online: Bug reference: 3820 Logged by: Sergey Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.beta4 Operating system: Windows Vista x64 Description:auto-installer-failed Details: I have 8.2 version work and running, also I want to try out 8.3.beta4 but it failed to install. Windows logs tells: Activation content creation error for "C:\Program Files (x86)\PostgreSQL\8.3-beta4\bin\initdb.exe". There is no "Microsoft.VC80.CRT,processorArchitecture="x86"". ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[BUGS] BUG #3919: Service Privileges Bug
The following bug has been logged online: Bug reference: 3919 Logged by: Sergey Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3RC2 Operating system: Windows 2003 SP2 Description:Service Privileges Bug Details: Postgre can't run under restricted user's account. Even if: 1) All 'service' rights to that account granted; 2) All 'disk' rights also granted (checked very carefully, '/data' in full access, other dirs read and execute); The error is 'Error 5 : Access denied'. Changing the user to 'Local Service' solves the issue. p.s. Postgre 8.2 on the same machine under restricted user with same priveleges running quite. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #5484: sum() bug
The following bug has been logged online: Bug reference: 5484 Logged by: Sergey Email address: vi...@yandex.ru PostgreSQL version: 8.4.4 Operating system: FreeBSD 7.3 Description:sum() bug Details: Function sum() bug. 8849.15+6464.57=15313.72 But sum()=15313.7 [r...@proxy ~]# psql -U pgsql megafon psql (8.4.4) Type "help" for help. megafon=# SELECT version(); version - PostgreSQL 8.4.4 on i386-portbld-freebsd7.3, compiled by GCC cc (GCC) 4.2.1 20070719 [FreeBSD], 32-bit (1 row) megafon=# megafon=# SELECT * from aaa; num - 8849.15 6464.57 (2 rows) megafon=# SELECT sum(num) from aaa; sum - 15313.7 (1 row) megafon=# -- 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 #5553: Repeating the keyword DECLARE in the CREATE FUNCTION statement
The following bug has been logged online: Bug reference: 5553 Logged by: Sergey Email address: s...@mail.ur.ru PostgreSQL version: 9 beta 2 Operating system: Windows XP Description:Repeating the keyword DECLARE in the CREATE FUNCTION statement Details: Is it a normal behavior of the parser: CREATE OR REPLACE FUNCTION row_ret13(b_in IN BOOLEAN = true or false, INTEGER DEFAULT 0 ) RETURNS BOOLEAN AS $$ DECLARE DECLARE DECLARE a integer DEFAULT 32; DECLARE DECLARE DECLARE DECLARE DECLARE b integer DEFAULT 32; DECLARE DECLARE BEGIN RETURN FALSE OR b_in; END; $$ LANGUAGE PLPGSQL; - Parsed. select row_ret13(); == t Thanks, Sergey. -- 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 #6242: ERROR: unexpected CASE WHEN clause: 333
The following bug has been logged online: Bug reference: 6242 Logged by: Sergey Email address: sergey-1...@yandex.ru PostgreSQL version: 8.4.4 Operating system: FreeBSD 8.1-RELEASE Description:ERROR: unexpected CASE WHEN clause: 333 Details: create view test_view as select case n when null then 1 when 1 then 2 when 2 then 3 end from ( values (null), (1), (2) ) as t(n) pg_dump then fail with error: "ERROR: unexpected CASE WHEN clause: 333" but select * from test_view does not. This error occurs with the configuration "transform_null_equals". -- 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 #7641: ERROR: must specify relation and object name when function contains DROP TRIGGER
The following bug has been logged on the website: Bug reference: 7641 Logged by: Sergey Email address: ser...@booksys.com PostgreSQL version: 9.2.1 Operating system: Windows XP / Ubuntu 10.04 (Lucid) Description: Postgres 9.2.1 Reproduced the problem on Windows XP and Ubuntu 10.04 Steps to reproduce: 1. Create a new database: CREATE DATABASE test; Connect to the new database. 2. CREATE TABLE test1 (id int); 3. CREATE OR REPLACE FUNCTION drop_trigger_test() RETURNS void AS $$ BEGIN DROP TRIGGER IF EXISTS invalid_trigger ON test1; END; $$ LANGUAGE plpgsql; 4. SELECT drop_trigger_test(); Result: NOTICE: trigger "invalid_trigger" for table "test1" does not exist, skipping CONTEXT: SQL statement "DROP TRIGGER IF EXISTS invalid_trigger ON test1" PL/pgSQL function drop_trigger_test() line 3 at SQL statement 5. SELECT drop_trigger_test(); Result: ERROR: must specify relation and object name CONTEXT: SQL statement "drop trigger if exists invalid_trigger on test2" PL/pgSQL function drop_trigger_test2() line 3 at SQL statement For some reason I can run this function without error only once on a fresh connection. Did not have this problem in 8.4.x and 9.1.6 -- 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 #7641: ERROR: must specify relation and object name when function contains DROP TRIGGER
Tom, There is also a minor bug when trying to do same thing with RULE (it doesn't produce an error but the notice is not correct when function is called for the second time): CREATE OR REPLACE FUNCTION drop_rule_test() RETURNS void AS $$ BEGIN DROP RULE IF EXISTS invalid_rule ON test1; END; $$ LANGUAGE plpgsql; SELECT drop_rule_test(); NOTICE: rule "invalid_rule" for relation "test1" does not exist, skipping CONTEXT: SQL statement "DROP RULE IF EXISTS invalid_rule ON test1" PL/pgSQL function drop_rule_test() line 3 at SQL statement SELECT drop_rule_test(); NOTICE: rule "test1" for relation "" does not exist, skipping CONTEXT: SQL statement "DROP RULE IF EXISTS invalid_rule ON test1" PL/pgSQL function drop_rule_test() line 3 at SQL statement Thanks, Sergey On 11/8/2012 10:14 AM, Tom Lane wrote: ser...@booksys.com writes: CREATE OR REPLACE FUNCTION drop_trigger_test() RETURNS void AS $$ BEGIN DROP TRIGGER IF EXISTS invalid_trigger ON test1; END; $$ LANGUAGE plpgsql; 4. SELECT drop_trigger_test(); Result: NOTICE: trigger "invalid_trigger" for table "test1" does not exist, skipping CONTEXT: SQL statement "DROP TRIGGER IF EXISTS invalid_trigger ON test1" PL/pgSQL function drop_trigger_test() line 3 at SQL statement 5. SELECT drop_trigger_test(); Result: ERROR: must specify relation and object name CONTEXT: SQL statement "drop trigger if exists invalid_trigger on test2" PL/pgSQL function drop_trigger_test2() line 3 at SQL statement For some reason I can run this function without error only once on a fresh connection. Did not have this problem in 8.4.x and 9.1.6 That's a bug all right --- the does_not_exist_skipping() function thinks it's okay to trash its input data structure, so the DropStmt is corrupted for next time. Will fix, thanks for the report! regards, tom lane -- 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 #4622: xpath only work in utf-8 server encoding
The following bug has been logged online:
Bug reference: 4622
Logged by: Sergey Burladyan
Email address: eshkin...@gmail.com
PostgreSQL version: 8.3.5
Operating system: Debian testing
Description:xpath only work in utf-8 server encoding
Details:
hello, all !
i am trying for test parse xml string in other than utf-8 encoding, it
correctly loaded but xpath(text, xml) can't handle it:
s...@seb:~/tmp/pg$ echo $LANG
ru_RU.CP1251
s...@seb:~/tmp/pg$ /usr/lib/postgresql/8.3/bin/postgres -p 5433 -k s -s -D .
LOG: система была отключена: 2009-01-22 16:30:07 MSK
LOG: autovacuum launcher started
LOG: database system is ready to accept connections
s...@seb:~$ echo $LANG
ru_RU.CP1251
s...@seb:~$ psql -h localhost -p 5433
Welcome to psql 8.3.5, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
seb=# select * from (select
xml('<русский>язык')) as x(v);
v
-
<русский>язык
(1 запись)
seb=# select xpath('/русский/text()', v::xml) from (select
xml('<русский>язык')) as x(v);
ERROR: could not parse XML data
DETAIL: Entity: line 1: parser error : Input is not proper UTF-8, indicate
encoding !
Bytes: 0xF0 0xF3 0xF1 0xF1
<русский>язык
^
seb=# select name, setting from pg_settings where name like 'lc_%' or name
like '%enco%';
name | setting
-+--
client_encoding | WIN1251
lc_collate | ru_RU.CP1251
lc_ctype| ru_RU.CP1251
lc_messages | ru_RU.CP1251
lc_monetary | ru_RU.CP1251
lc_numeric | ru_RU.CP1251
lc_time | ru_RU.CP1251
server_encoding | WIN1251
(8 rows)
in utf-8 server encoding it work correctly:
seb=> select xpath('/русский/text()', v::xml) from (select
xml('<русский>язык')) as x(v);
xpath
{язык}
(1 запись)
seb=> select name, setting from pg_settings where name like 'lc_%' or name
like '%enco%';
name | setting
-+-
client_encoding | UTF8
lc_collate | ru_RU.UTF-8
lc_ctype| ru_RU.UTF-8
lc_messages | ru_RU.UTF-8
lc_monetary | ru_RU.UTF-8
lc_numeric | ru_RU.UTF-8
lc_time | ru_RU.UTF-8
server_encoding | UTF8
(8 rows)
i am think something is wrong here, string parsed correctly by xml(text),
but it result can't pass to xpath function...
--
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 #4700: SIGSEGV with incorrect input to to_char function
The following bug has been logged online:
Bug reference: 4700
Logged by: Sergey Burladyan
Email address: eshkin...@gmail.com
PostgreSQL version: 8.3.6
Operating system: Debian GNU/Linux 5.0 (lenny)
Description:SIGSEGV with incorrect input to to_char function
Details:
this is for debian package:
seb=> select version();
version
PostgreSQL 8.3.6 on i486-pc-linux-gnu, compiled by GCC gcc-4.3.real (Debian
4.3.3-3) 4.3.3
seb=> select to_char(0, 'TMMON TMMon TMmon TMMONTH TMMonth TMDAY TMDay TMday
TMDY TMDy TMdy');
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
this is for current cvs REL8_3_STABLE
./configure --prefix=$HOME/inst/pg-dev --enable-nls='ru' --enable-debug
--enable-depend --enable-cassert --enable-thread-safety --with-pgport=5433
--with-libxml --with-libxslt
postgres=# select version();
version
---
PostgreSQL 8.3.6 on i686-pc-linux-gnu, compiled by GCC gcc (Debian 4.3.3-3)
4.3.3
Program received signal SIGSEGV, Segmentation fault.
parse_format (node=, str=0x9a02053 "ay TMday TMDY TMDy
TMdy", kw=0x83c7bc0, suf=0x0, index=0x83c7ec0,
ver=2, Num=0xbfe7d8a4) at formatting.c:3751
3751*ent->str = '\0';
(gdb) bt
#0 parse_format (node=, str=0x9a02053 "ay TMday TMDY
TMDy TMdy", kw=0x83c7bc0, suf=0x0,
index=0x83c7ec0, ver=2, Num=0xbfe7d8a4) at formatting.c:3751
#1 0x082c1804 in NUM_cache (len=66, Num=0xbfe7d8a4, pars_str=, shouldFree=0xbfe7d8cb "\001")
at formatting.c:3785
#2 0x082c34d0 in int4_to_char (fcinfo=0xbfe7d918) at formatting.c:4989
#3 0x0819733b in ExecMakeFunctionResult (fcache=0x99fdeb8,
econtext=0x99fde20,
isNull=0x99fe490 "\177~\177\177\177\177\177\177$\032\234\t@",
isDone=0x99fe4f0) at execQual.c:1351
#4 0x08194f75 in ExecProject (projInfo=0x99fe4a4, isDone=0xbfe7dbc8) at
execQual.c:4610
#5 0x081a8354 in ExecResult (node=0x99fdd94) at nodeResult.c:155
#6 0x0819416d in ExecProcNode (node=0x99fdd94) at execProcnode.c:319
#7 0x08191ed3 in ExecutorRun (queryDesc=0x99fd820,
direction=ForwardScanDirection, count=0) at execMain.c:1335
#8 0x082419db in PortalRunSelect (portal=0x99f4b84, forward=, count=0, dest=0x99f1d1c) at pquery.c:943
#9 0x082430fd in PortalRun (portal=0x99f4b84, count=2147483647,
isTopLevel=1 '\001', dest=0x99f1d1c, altdest=0x99f1d1c,
completionTag=0xbfe7de2a "") at pquery.c:797
#10 0x0823dabe in exec_simple_query (
query_string=0x99f0b74 "select to_char(0, 'TMMON TMMon TMmon TMMONTH
TMMonth TMDAY TMDay TMday TMDY TMDy TMdy');")
at postgres.c:1004
#11 0x0823f32c in PostgresMain (argc=4, argv=0x995cc14, username=0x995cbe4
"seb") at postgres.c:3631
#12 0x0820927f in ServerLoop () at postmaster.c:3207
#13 0x0820a203 in PostmasterMain (argc=5, argv=0x995aba0) at
postmaster.c:1029
#14 0x081b8346 in main (argc=5, argv=0x995aba0) at main.c:188
(gdb) list
3746NUM_cache_remove(NUMCacheEntry *ent)
3747{
3748#ifdef DEBUG_TO_FROM_CHAR
3749elog(DEBUG_elog_output, "REMOVING ENTRY (%s)", ent->str);
3750#endif
3751*ent->str = '\0';
3752ent->age = 0;
3753}
3754
3755/* --
cvs HEAD is also affected:
Program received signal SIGSEGV, Segmentation fault.
parse_format (node=, str=0x904742b "ay TMday TMDY TMDy
TMdy", kw=0x847b820, suf=0x0, index=0x847bb20,
ver=2, Num=0xbfdb57d4) at formatting.c:3473
3473*ent->str = '\0';
(gdb) bt
#0 parse_format (node=, str=0x904742b "ay TMday TMDY
TMDy TMdy", kw=0x847b820, suf=0x0,
index=0x847bb20, ver=2, Num=0xbfdb57d4) at formatting.c:3473
#1 0x082ff14a in NUM_cache (len=66, Num=0xbfdb57d4, pars_str=,
shouldFree=0xbfdb57fb
"\001�R\004\tstr);
3472#endif
3473*ent->str = '\0';
3474ent->age = 0;
3475}
3476
3477/* --
--
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 #4705: Software developer
Dave Page writes: -- С уважением, Сергей Бурладян -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] pg 8.3.7 libxml trying to free NULL pointer
This is CVS HEAD 8.3, Debian package 8.3.7 also affected.
libxml2: 2.7.3.dfsg-1 current version in debian testing.
postgres=# select version();
version
---
PostgreSQL 8.3.7 on i686-pc-linux-gnu, compiled by GCC gcc (Debian 4.3.3-3)
4.3.3
./configure --prefix=$HOME/inst/pg-dev --enable-nls --enable-debug
--enable-depend --enable-cassert --enable-thread-safety --with-pgport=5433
--with-libxml --with-libxslt
postgres=# select xpath('count(//)', ''::xml);
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: Succeeded.
TRAP: FailedAssertion("!(pointer != ((void *)0))", File: "mcxt.c", Line: 580)
LOG: server process (PID 30335) was terminated by signal 6: Aborted
Program received signal SIGABRT, Aborted.
0xb7f90424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7f90424 in __kernel_vsyscall ()
#1 0xb7c59640 in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7c5b008 in *__GI_abort () at abort.c:88
#3 0x082efcae in ExceptionalCondition (conditionName=0x83d6832 "!(pointer !=
((void *)0))",
errorType=0x83237a2 "FailedAssertion", fileName=0x83d682b "mcxt.c",
lineNumber=580) at assert.c:57
#4 0x0830f1cc in pfree (pointer=0x0) at mcxt.c:580
#5 0xb7e6e5d2 in ?? () from /usr/lib/libxml2.so.2
#6 0x in ?? ()
--
Sergey Burladyan
--
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] pg 8.3.7 libxml trying to free NULL pointer
I am install libxml2-dbg 2.7.3.dfsg-1 package, this is backtrace with it:
Program received signal SIGABRT, Aborted.
0xb7f17424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7f17424 in __kernel_vsyscall ()
#1 0xb7be0640 in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7be2008 in *__GI_abort () at abort.c:88
#3 0x082efcae in ExceptionalCondition (conditionName=0x83d6832 "!(pointer !=
((void *)0))",
errorType=0x83237a2 "FailedAssertion", fileName=0x83d682b "mcxt.c",
lineNumber=580) at assert.c:57
#4 0x0830f1cc in pfree (pointer=0x0) at mcxt.c:580
#5 0xb7df55d2 in xmlXPathCompPathExpr (ctxt=0x88a020c) at xpath.c:10312
#6 0xb7df58cd in xmlXPathCompUnaryExpr (ctxt=0x88a020c) at xpath.c:10616
#7 0xb7df5b0f in xmlXPathCompMultiplicativeExpr (ctxt=0x0) at xpath.c:10681
#8 0xb7df5cef in xmlXPathCompAdditiveExpr (ctxt=0x0) at xpath.c:10722
#9 0xb7df5e7f in xmlXPathCompRelationalExpr (ctxt=0x0) at xpath.c:10760
#10 0xb7df600f in xmlXPathCompEqualityExpr (ctxt=0x0) at xpath.c:10802
#11 0xb7df61cf in xmlXPathCompAndExpr (ctxt=0x0) at xpath.c:10833
#12 0xb7df6342 in xmlXPathCompileExpr (ctxt=0x0, sort=6) at xpath.c:10859
#13 0xb7dfd390 in xmlXPathCtxtCompile__internal_alias (ctxt=0x0, str=0x88b03d8
"count(//)") at xpath.c:14612
#14 0xb7dfd459 in xmlXPathCompile__internal_alias (str=0x88b03d8 "count(//)")
at xpath.c:14663
#15 0x082da303 in xpath (fcinfo=0xbfe322a8) at xml.c:3465
#16 0x081975bb in ExecMakeFunctionResult (fcache=0x88ae670, econtext=0x88ae5d8,
isNull=0x88aec78 "\177~\177\177\177\177\177\177��\206\b@",
isDone=0x88aecd8) at execQual.c:1351
#17 0x081951f5 in ExecProject (projInfo=0x88aec8c, isDone=0xbfe32558) at
execQual.c:4610
#18 0x081a8614 in ExecResult (node=0x88ae54c) at nodeResult.c:155
#19 0x081943ed in ExecProcNode (node=0x88ae54c) at execProcnode.c:319
#20 0x08192153 in ExecutorRun (queryDesc=0x88adb00,
direction=ForwardScanDirection, count=1) at execMain.c:1335
#21 0x0819e807 in postquel_getnext (es=0x88ada8c, fcache=0x88ad174) at
functions.c:378
#22 0x0819ecc2 in fmgr_sql (fcinfo=0xbfe327f8) at functions.c:479
#23 0x081975bb in ExecMakeFunctionResult (fcache=0x88ac668, econtext=0x88ac5d0,
isNull=0x88acd40 "", isDone=0x88acd54)
at execQual.c:1351
#24 0x081951f5 in ExecProject (projInfo=0x88acc48, isDone=0xbfe32aa8) at
execQual.c:4610
#25 0x081a8614 in ExecResult (node=0x88ac544) at nodeResult.c:155
#26 0x081943ed in ExecProcNode (node=0x88ac544) at execProcnode.c:319
#27 0x08192153 in ExecutorRun (queryDesc=0x88abfd0,
direction=ForwardScanDirection, count=0) at execMain.c:1335
#28 0x08241eab in PortalRunSelect (portal=0x88a31dc, forward=, count=0, dest=0x889a274) at pquery.c:943
#29 0x082435cd in PortalRun (portal=0x88a31dc, count=2147483647, isTopLevel=1
'\001', dest=0x889a274, altdest=0x889a274,
completionTag=0xbfe32d0a "") at pquery.c:797
#30 0x0823df8e in exec_simple_query (query_string=0x88991bc "select
xpath('count(//)', ''::xml);") at postgres.c:1004
#31 0x0823f7fc in PostgresMain (argc=4, argv=0x8810cf4, username=0x8810cc4
"seb") at postgres.c:3631
#32 0x0820973f in ServerLoop () at postmaster.c:3207
#33 0x0820a6c3 in PostmasterMain (argc=4, argv=0x880ec88) at postmaster.c:1029
#34 0x081b8606 in main (argc=4, argv=0x880ec88) at main.c:188
--
Sergey Burladyan
--
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 #4907: stored procedures and changed tables
Alvaro Herrera writes: > Michael Tenenbaum wrote: > > > If I have a stored procedure that returns a set of records of a table, I get > > an error message that the procedure's record is the wrong type after I > > change some columns in the table. > > > > Deleting the procedure then rewriting the procedure does not help. The only > > thing that works is deleting both the stored procedure and the table and > > starting over again. > > Does it work if you disconnect and connect again? No, example: PostgreSQL 8.4.0 on i486-pc-linux-gnu, compiled by GCC gcc-4.3.real (Debian 4.3.3-13) 4.3.3, 32-bit create table t (i int); create function foo() returns setof t language plpgsql as $$begin return query select * from t; end$$; select foo(); alter table t add v text; alter table t drop i; select foo(); ERROR: 42804: structure of query does not match function result type ПОДРОБНО: Number of returned columns (1) does not match expected column count (2). КОНТЕКСТ: PL/pgSQL function "foo" line 1 at RETURN QUERY РАСПОЛОЖЕНИЕ: validate_tupdesc_compat, pl_exec.c:5143 drop function foo(); \c psql (8.4.0) You are now connected to database "seb". create function foo() returns setof t language plpgsql as $$begin return query select * from t; end$$; select foo(); ERROR: 42804: structure of query does not match function result type ПОДРОБНО: Number of returned columns (1) does not match expected column count (2). КОНТЕКСТ: PL/pgSQL function "foo" line 1 at RETURN QUERY РАСПОЛОЖЕНИЕ: validate_tupdesc_compat, pl_exec.c:5143 -- Sergey Burladyan -- 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 #4907: stored procedures and changed tables
Sergey Burladyan writes: > Alvaro Herrera writes: > > > Michael Tenenbaum wrote: > > > > > If I have a stored procedure that returns a set of records of a table, I > > > get > > > an error message that the procedure's record is the wrong type after I > > > change some columns in the table. > > > > > > Deleting the procedure then rewriting the procedure does not help. The > > > only > > > thing that works is deleting both the stored procedure and the table and > > > starting over again. > > > > Does it work if you disconnect and connect again? > > No, example: More simple: PostgreSQL 8.4.0 on i486-pc-linux-gnu, compiled by GCC gcc-4.3.real (Debian 4.3.3-13) 4.3.3, 32-bit create table t (i int); alter table t add v text; alter table t drop i; create function foo() returns setof t language plpgsql as $$begin return query select * from t; end$$; select foo(); ERROR: 42804: structure of query does not match function result type ПОДРОБНО: Number of returned columns (1) does not match expected column count (2). КОНТЕКСТ: PL/pgSQL function "foo" line 1 at RETURN QUERY РАСПОЛОЖЕНИЕ: validate_tupdesc_compat, pl_exec.c:5143 So, function with RETURNS SETOF tbl does not work if it created after ALTER TABLE 8.3.7 too: PostgreSQL 8.3.7 on i486-pc-linux-gnu, compiled by GCC gcc-4.3.real (Debian 4.3.3-5) 4.3.3 create table t (i int); alter table t add v text; alter table t drop i; create function foo() returns setof t language plpgsql as $$begin return query select * from t; end$$; select * from foo(); ERROR: 42804: structure of query does not match function result type КОНТЕКСТ: PL/pgSQL function "foo" line 1 at RETURN QUERY РАСПОЛОЖЕНИЕ: exec_stmt_return_query, pl_exec.c:2173 -- Sergey Burladyan -- 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 #4922: Segmentation fault on high-loaded server (+coredump backtrace)
The following bug has been logged online: Bug reference: 4922 Logged by: Sergey Konoplev Email address: gray...@gmail.com PostgreSQL version: 8.3.5 Operating system: CentOS 5.2 x86-64 Description:Segmentation fault on high-loaded server (+coredump backtrace) Details: Hello, community. We faced this segfault few times during the last couple of days. This days our server was extremly loaded. Before and after this period when LA was quite normal everything was alright. I'll do my best answering your questions, so please ask. Two coredumps backtraces bellow: Core was generated by `postgres: mirtesen mirtesen [local] UPDATE'. Program terminated with signal 11, Segmentation fault. [New process 8912] #0 0x0065ecf3 in pfree () (gdb) bt #0 0x0065ecf3 in pfree () #1 0x2b1a2e1fab2e in ?? () from /usr/lib64/pgsql/pgq_triggers.so #2 0x00639d41 in ?? () #3 0x0059840c in ReceiveSharedInvalidMessages () #4 0x0059a735 in LockRelationOid () #5 0x0045cf95 in relation_open () #6 0x004620bb in index_open () #7 0x00461187 in systable_beginscan () #8 0x0063b496 in ?? () #9 0x0063da7d in ?? () #10 0x0063e354 in RelationCacheInvalidateEntry () #11 0x00639cfd in ?? () #12 0x0059840c in ReceiveSharedInvalidMessages () #13 0x0059a735 in LockRelationOid () #14 0x0045cf95 in relation_open () #15 0x0045cfd3 in heap_open () #16 0x0063b463 in ?? () #17 0x0063da7d in ?? () #18 0x0063e354 in RelationCacheInvalidateEntry () #19 0x00639cfd in ?? () #20 0x0059840c in ReceiveSharedInvalidMessages () #21 0x0059a735 in LockRelationOid () #22 0x0063a539 in ?? () #23 0x0063a7e9 in RevalidateCachedPlan () #24 0x0052f142 in ?? () #25 0x0052f453 in SPI_execute_plan () #26 0x2b1a2e1fad9b in pgq_find_table_info () from /usr/lib64/pgsql/pgq_triggers.so #27 0x2b1a2e1fb05a in pgq_prepare_event () from /usr/lib64/pgsql/pgq_triggers.so #28 0x2b1a2e1fb68f in pgq_logtriga () from /usr/lib64/pgsql/pgq_triggers.so #29 0x004fc35c in ?? () #30 0x004fc74e in ?? () #31 0x004fc9d7 in AfterTriggerEndQuery () #32 0x005a9450 in ?? () #33 0x005a9624 in ?? () #34 0x005a9e4a in PortalRun () #35 0x005a5651 in ?? () #36 0x005a6ec8 in PostgresMain () #37 0x0057d28d in ?? () #38 0x0057dd69 in PostmasterMain () #39 0x0053709e in main () (gdb) Core was generated by `postgres: mirtesen mirtesen [local] INSERT'. Program terminated with signal 11, Segmentation fault. [New process 31998] #0 0x0038fe878d80 in strlen () from /lib64/libc.so.6 (gdb) bt #0 0x0038fe878d80 in strlen () from /lib64/libc.so.6 #1 0x0052fefc in appendStringInfoString () #2 0x2af2c47076b1 in pgq_logtriga () from /usr/lib64/pgsql/pgq_triggers.so #3 0x004fc35c in ?? () #4 0x004fc74e in ?? () #5 0x004fc9d7 in AfterTriggerEndQuery () #6 0x005a9450 in ?? () #7 0x005a9624 in ?? () #8 0x005a9829 in ?? () #9 0x005a9e68 in PortalRun () #10 0x005a5651 in ?? () #11 0x005a6ec8 in PostgresMain () #12 0x0057d28d in ?? () #13 0x0057dd69 in PostmasterMain () #14 0x0053709e in main () (gdb) -- 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 #5078: returns setof functions fails after table structure altered
The following bug has been logged online:
Bug reference: 5078
Logged by: Sergey Manakov
Email address: vial...@gmail.com
PostgreSQL version: 8.4.1
Operating system: Fedora Core 11
Description:returns setof functions fails after table structure
altered
Details:
Hi! I'am from Russia and write English ugly, but i'am must to try...
Just repeat steps below:
CREATE TABLE biz_uks
(
id serial NOT NULL,
rid timestamp(0) without time zone NOT NULL DEFAULT
('now'::text)::timestamp without time zone,
title character varying NOT NULL,
otitles character varying,
adrfact character varying NOT NULL,
station character varying,
region integer,
zipcode character varying,
phone character varying NOT NULL,
fax character varying,
url character varying,
mail character varying,
techabout text,
remark character varying,
cnlastdate date,
CONSTRAINT pk_biz_uks PRIMARY KEY (id),
CONSTRAINT uq_biz_uks UNIQUE (title)
);
COMMENT ON TABLE biz_uks IS 'Справочник управляющих
компаний';
alter table biz_uks
drop column remark
;
drop function if exists set__biz_uks();
create or replace function set__biz_uks()
returns biz_uks
security definer volatile language plpgsql as $$
declare
res biz_uks;
begin
return res;
end;
$$ ;
select * from set__biz_uks();
drop function if exists set__biz_uks();
create or replace function set__biz_uks()
returns setof biz_uks
security definer volatile language plpgsql as $$
declare
res biz_uks;
begin
return query
select res.*;
end;
$$ ;
select * from set__biz_uks();
Last command will raise exception!
--
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 #5094: bad result in dblink_get_result when async command sending
The following bug has been logged online:
Bug reference: 5094
Logged by: Sergey Tomoulevitch
Email address: phoinix.pub...@gmail.com
PostgreSQL version: 8.4
Operating system: any
Description:bad result in dblink_get_result when async command
sending
Details:
Good day!
I find one bug in your function dblink_get_result.
When I send command in async query, eq:
SELECT dblink_send_query('remoteconn', 'INSERT INTO mytable (f1, f2) VALUES
(1,2);');
I can not get result for this, eq:
SELECT dblink_get_result('remoteconn');
I got error "ERRCODE_DATATYPE_MISMATCH".
May be...
if (PQnfields(res) != tupdesc->natts)...
is so bad, because PQnfields(res) - is empty for command?
--
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 #5159: 8.4.1 Segmentation fault
The following bug has been logged online: Bug reference: 5159 Logged by: Sergey Konoplev Email address: gray...@gmail.com PostgreSQL version: 8.4.1 Operating system: CentOS release 5.4 (Final) Description:8.4.1 Segmentation fault Details: Hello Contribs: btree_gist hstore btree_gin (hasn't been used yet) After migration to 8.4.1 from 8.3.7 our server worked normally for half our and then become falling down continuously with "Segmentation fault". I did two codedumps and bt on it: Core was generated by `postgres: mirtesen mirtesen [local] INSERT'. Program terminated with signal 11, Segmentation fault. [New process 9238] #0 0x006646e1 in ?? () (gdb) bt #0 0x006646e1 in ?? () #1 0x00665545 in ts_stat1 () #2 0x005390b7 in ExecMakeTableFunctionResult () #3 0x005454e1 in ?? () #4 0x0053a390 in ExecScan () #5 0x0053373a in ExecProcNode () #6 0x0053148f in standard_ExecutorRun () #7 0x0054e546 in ?? () #8 0x0054e980 in SPI_execute_plan () #9 0x2ade2044d06d in ?? () from /usr/lib64/pgsql/plpgsql.so #10 0x2ade2044f7f2 in ?? () from /usr/lib64/pgsql/plpgsql.so #11 0x2ade2044f300 in ?? () from /usr/lib64/pgsql/plpgsql.so #12 0x2ade20451482 in plpgsql_exec_trigger () from /usr/lib64/pgsql/plpgsql.so #13 0x2ade2044783a in plpgsql_call_handler () from /usr/lib64/pgsql/plpgsql.so #14 0x0051647b in ?? () #15 0x00516826 in ?? () #16 0x00516f7e in AfterTriggerEndQuery () #17 0x005d560b in ?? () #18 0x005d57d9 in ?? () #19 0x005d59d9 in ?? () #20 0x005d5fc3 in PortalRun () #21 0x005d1c65 in ?? () #22 0x005d28fb in PostgresMain () #23 0x005a9a29 in ?? () #24 0x005aa5fe in PostmasterMain () #25 0x005589fe in main () (gdb) Core was generated by `postgres: mirtesen mirtesen [local] INSERT'. Program terminated with signal 11, Segmentation fault. [New process 10384] #0 0x006646e1 in ?? () (gdb) bt #0 0x006646e1 in ?? () #1 0x00665545 in ts_stat1 () #2 0x005390b7 in ExecMakeTableFunctionResult () #3 0x005454e1 in ?? () #4 0x0053a390 in ExecScan () #5 0x0053373a in ExecProcNode () #6 0x0053148f in standard_ExecutorRun () #7 0x0054e546 in ?? () #8 0x0054e980 in SPI_execute_plan () #9 0x2ade201c506d in ?? () from /usr/lib64/pgsql/plpgsql.so #10 0x2ade201c77f2 in ?? () from /usr/lib64/pgsql/plpgsql.so #11 0x2ade201c7300 in ?? () from /usr/lib64/pgsql/plpgsql.so #12 0x2ade201c9482 in plpgsql_exec_trigger () from /usr/lib64/pgsql/plpgsql.so #13 0x2ade201bf83a in plpgsql_call_handler () from /usr/lib64/pgsql/plpgsql.so #14 0x0051647b in ?? () #15 0x00516826 in ?? () #16 0x00516f7e in AfterTriggerEndQuery () #17 0x005d560b in ?? () #18 0x005d57d9 in ?? () #19 0x005d59d9 in ?? () #20 0x005d5fc3 in PortalRun () #21 0x005d1c65 in ?? () #22 0x005d28fb in PostgresMain () #23 0x005a9a29 in ?? () #24 0x005aa5fe in PostmasterMain () #25 0x005589fe in main () (gdb) Regards, Sergey Konoplev -- 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 #5159: 8.4.1 Segmentation fault
Thanx, Tom. So I just need to checkout REL8_4_STABLE and install it to fix my problem, right? On Mon, Nov 2, 2009 at 7:48 PM, Tom Lane wrote: > "Sergey Konoplev" writes: >> After migration to 8.4.1 from 8.3.7 our server worked normally for half our >> and then become falling down continuously with "Segmentation fault". I did >> two codedumps and bt on it: > >> Core was generated by `postgres: mirtesen mirtesen [local] INSERT '. >> Program terminated with signal 11, Segmentation fault. >> [New process 9238] >> #0 0x006646e1 in ?? () >> (gdb) bt >> #0 0x006646e1 in ?? () >> #1 0x00665545 in ts_stat1 () >> #2 0x005390b7 in ExecMakeTableFunctionResult () > > Hmm, maybe this is this bug: > http://archives.postgresql.org/pgsql-committers/2009-10/msg00056.php > > If not, we are going to need more information than this to fix it. > > regards, tom lane > -- Regards, Sergey Konoplev -- PostgreSQL articles in english & russian http://gray-hemp.blogspot.com/search/label/postgresql/ -- 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 #5159: 8.4.1 Segmentation fault
On Mon, Nov 2, 2009 at 8:25 PM, Stefan Kaltenbrunner wrote: > Sergey Konoplev wrote: >> >> Thanx, Tom. >> >> So I just need to checkout REL8_4_STABLE and install it to fix my >> problem, right? > > that should work if it is indeed the same issue. > What if I apply this patch to 8.4.1? Would I get the same result? http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/tsvector_op.c?r1=1.23&r2=1.23.2.1 -- Regards, Sergey Konoplev -- 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 #5159: 8.4.1 Segmentation fault
Thank you. Will try. On Mon, Nov 2, 2009 at 8:40 PM, Stefan Kaltenbrunner wrote: > Sergey Konoplev wrote: >> >> On Mon, Nov 2, 2009 at 8:25 PM, Stefan Kaltenbrunner >> wrote: >>> >>> Sergey Konoplev wrote: >>>> >>>> Thanx, Tom. >>>> >>>> So I just need to checkout REL8_4_STABLE and install it to fix my >>>> problem, right? >>> >>> that should work if it is indeed the same issue. >>> >> >> What if I apply this patch to 8.4.1? Would I get the same result? >> >> >> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/tsvector_op.c?r1=1.23&r2=1.23.2.1 > > > yep - it should have the same effect > > Stefan > -- Regards, Sergey Konoplev -- PostgreSQL articles in english & russian http://gray-hemp.blogspot.com/search/label/postgresql/ -- 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 #5234: ALTER TABLE ... RENAME COLUMN change view definition incorrectly
The following bug has been logged online: Bug reference: 5234 Logged by: Sergey Burladyan Email address: eshkin...@gmail.com PostgreSQL version: 8.3.8 Operating system: Debian GNU/Linux 5.0.3 (lenny) + testing Description:ALTER TABLE ... RENAME COLUMN change view definition incorrectly Details: reported by Weed at http://www.sql.ru/forum/actualthread.aspx?tid=717835 (Russian) Example: create table a (i int, v text); create table b (j int, v text); create view v_using as select * from a left join b using (v); alter table a rename v to o; \d v_using CREATE TABLE CREATE TABLE CREATE VIEW ALTER TABLE View "public.v_using" Column | Type | Modifiers +-+--- v | text| i | integer | j | integer | View definition: SELECT a.o AS v, a.i, b.j FROM a LEFT JOIN b USING (v); View is still working, but it text definition is incorrect: t1=> select * from v_using ; v | i | j ---+---+--- (0 rows) t1=> SELECT a.o AS v, a.i, b.j t1->FROM a t1->LEFT JOIN b USING (v); ERROR: 42703: column "v" specified in USING clause does not exist in left table LOCATION: transformFromClauseItem, parse_clause.c:813 If you dump database in this state, when you cannot restore this dump without manual fix: $ pg_dump -Fc -f dump t1 $ pg_restore dump | grep -A2 VIEW -- Name: v_using; Type: VIEW; Schema: public; Owner: seb -- CREATE VIEW v_using AS SELECT a.o AS v, a.i, b.j FROM (a LEFT JOIN b USING (v)); $ LANG=C sudo -u postgres pg_restore -c -d t1 dump . . . pg_restore: [archiver (db)] could not execute query: ERROR: column "v" specified in USING clause does not exist in left table Command was: CREATE VIEW v_using AS SELECT a.o AS v, a.i, b.j FROM (a LEFT JOIN b USING (v)); . . . -- 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 #5360: system column named "text"
The following bug has been logged online: Bug reference: 5360 Logged by: Sergey Manakov Email address: vial...@gmail.com PostgreSQL version: 8.4.2 Operating system: Fedora Core 8 Description:system column named "text" Details: Hi! I'am from Russia and write English ugly, but i'am must to try... I have some table with column named "remark" and without column named "text". I wrote SQL where try to select column named "text" by mistake: SELECT st.text FROM sometable st Where error expected, but query executed without error! Query result is one column contains text representation of ROWs. Is this a bug, or I'am look for description in docs badly? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] POSTGRES BUG - FIX IT PLEASE
I attach bug.template file with description of my problem. Please fix it asap. -- Keep in touch. Sergey Mavrinsky. Solvo Ltd. If PostgreSQL failed to compile on your computer or you found a bug that is likely to be specific to one platform then please fill out this form and e-mail it to [EMAIL PROTECTED] To report any other bug, fill out the form below and e-mail it to [EMAIL PROTECTED] If you not only found the problem but solved it and generated a patch then e-mail it to [EMAIL PROTECTED] instead. Please use the command "diff -c" to generate the patch. You may also enter a bug report at http://www.postgresql.org/ instead of e-mail-ing this form. POSTGRESQL BUG REPORT TEMPLATE Your name : Mavrinsky Sergey Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel Pentium 366Mz Operating System (example: Linux 2.0.26 ELF) : RedHat 6.0 PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.2 Compiler used (example: gcc 2.8.0) : 2.91 Please enter a FULL description of your problem: I have found a following problem: I have 2 tables create table t1 ( f1 integer, f2 integer ); create table t2 ( f1 integer references t1(f1), f2 integer ); Then in a query: begin transaction; insert into t1(f1,f2) values(1,1); delete from t1 where f1=1; at that moment the following error occurs: ERROR: triggered data change violation on relation "t1" by the way, when i create referentional constraint Postrgers server creates trigger... Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- create database db1; create table t1 ( f1 integer, f2 integer ); create table t2 ( f1 integer references t1(f1), f2 integer ); begin transaction; insert into t1(f1,f2) values(1,1); delete from t1 where f1=1; ERROR: triggered data change violation on relation "t1" If you know how this problem might be fixed, list the solution below: - ?
[BUGS] BUG #2517: Trouble with cx_Oracle and Plpython
The following bug has been logged online:
Bug reference: 2517
Logged by: Sergey Konoplev
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: SUSE LINUX Enterprise Server 9
Description:Trouble with cx_Oracle and Plpython
Details:
Good day.
Iâve got a trouble with cx_Oracle and Plpython (PostgreSQL).
The function DDL:
CREATE OR REPLACE FUNCTION "public"."function1" () RETURNS varchar AS
$body$
import cx_Oracle
connection = cx_Oracle.connect('xxx', 'xxx', 'xxx')
$body$
LANGUAGE 'plpythonu' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER;
The function has executed successfully via psql interactive tool with local
transport.
pgdb:/ # /opt/PostgreSQL/bin/psql -U postgres -d transport
Welcome to psql 8.1.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
transport=# select * from function1();
function1
---
(1 row)
transport=#
But ORA-12154 error has been raised via same tool with remote transport.
pgdb:/ # /opt/PostgreSQL/bin/psql -U postgres -d transport -h
192.168.101.181
Password for user postgres:
Welcome to psql 8.1.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
transport=# select * from function1();
ERROR: plpython: function "function1" failed
DETAIL: cx_Oracle.DatabaseError: ORA-12154: TNS:could not resolve the
connect identifier specified
transport=#
How can I solve this problem?
Regards,
Konoplev Sergey <[EMAIL PROTECTED]>
Sen. software dveloper, IT department
Tander JSC
-
Levanevskogo st. 185, Krasnodar city, RUSSIA
Phone +7 861 210-98-10 (add.233)
Icq 29353802
---(end of broadcast)---
TIP 6: explain analyze is your friend
[BUGS] IYYY: unexpected behaviour
Hi, SELECT to_char( '2006-01-01'::timestamp, 'IYYY-MM-DD' ) AS strange, to_char( '2006-01-02'::timestamp, 'IYYY-MM-DD' ), to_char( '2006-01-01'::timestamp, '-MM-DD' ); does produce unexpected result for column ‘strange’: strange | to_char | to_char ++ 2005-01-01 | 2006-01-02 | 2006-01-01 (1 row) Is this a bug? select version(); "PostgreSQL 8.2beta1 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special)"
[BUGS] PG unexpected crash
select version(); "PostgreSQL 8.2.1 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special)" pg_log: 2007-01-12 16:41:23 STATEMENT: EXPLAIN COPY "MsgRoot" TO 'C:/Program Files/PostgreSQL/8.2/data/MsgRoot.txt' 2007-01-12 17:16:04 LOG: checkpoints are occurring too frequently (11 seconds apart) 2007-01-12 17:16:04 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:16:14 LOG: checkpoints are occurring too frequently (10 seconds apart) 2007-01-12 17:16:14 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:16:36 LOG: checkpoints are occurring too frequently (22 seconds apart) 2007-01-12 17:16:36 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:16:47 LOG: checkpoints are occurring too frequently (11 seconds apart) 2007-01-12 17:16:47 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:16:57 LOG: checkpoints are occurring too frequently (10 seconds apart) 2007-01-12 17:16:57 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:17:07 LOG: checkpoints are occurring too frequently (10 seconds apart) 2007-01-12 17:17:07 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:20:47 LOG: checkpoints are occurring too frequently (8 seconds apart) 2007-01-12 17:20:47 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:21:01 LOG: checkpoints are occurring too frequently (14 seconds apart) 2007-01-12 17:21:01 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:21:07 LOG: checkpoints are occurring too frequently (6 seconds apart) 2007-01-12 17:21:07 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:21:22 LOG: checkpoints are occurring too frequently (15 seconds apart) 2007-01-12 17:21:22 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:21:30 LOG: checkpoints are occurring too frequently (8 seconds apart) 2007-01-12 17:21:30 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:21:43 LOG: checkpoints are occurring too frequently (13 seconds apart) 2007-01-12 17:21:43 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:21:50 LOG: checkpoints are occurring too frequently (7 seconds apart) 2007-01-12 17:21:50 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:22:04 LOG: checkpoints are occurring too frequently (14 seconds apart) 2007-01-12 17:22:04 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:22:12 LOG: checkpoints are occurring too frequently (8 seconds apart) 2007-01-12 17:22:12 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:22:26 LOG: checkpoints are occurring too frequently (14 seconds apart) 2007-01-12 17:22:26 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:22:32 LOG: checkpoints are occurring too frequently (6 seconds apart) 2007-01-12 17:22:32 HINT: Consider increasing the configuration parameter "checkpoint_segments". 2007-01-12 17:22:41 NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "part_2007011400_MsgRoot_pkey" for table "part_2007011400_MsgRoot" 2007-01-12 17:23:16 PANIC: could not open control file "global/pg_control": Permission denied 2007-01-12 17:23:16 CONTEXT: COPY part_2007011400_MsgRoot, line 111982 2007-01-12 17:23:16 STATEMENT: COPY "part_2007011400_MsgRoot" FROM 'C:/Program Files/PostgreSQL/8.2/data/MsgRoot.bin' WITH BINARY; This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. 2007-01-12 17:23:16 LOG: server process (PID 1224) exited with exit code 3 2007-01-12 17:23:16 LOG: terminating any other active server processes 2007-01-12 17:23:16 WARNING: terminating connection because of crash of another server process 2007-01-12 17:23:16 DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2007-01-12 17:23:16 HINT: In a moment you should be able to reconnect to the database and repeat your command. 2007-01-12 17:23:16 WARNING: terminating connection because of crash of another server process 2007-01-12 17:23:17 DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2007-01-12 17:23:17 HINT: In a moment you should be able to reconnect to the database and repeat you
[BUGS] "Permission denied" failures occurring on Windows
Hello. In spite of the fact that as it was outlined in the "change log" to PostgreSQL 8.2.2, the bug of the periodical "permission denied" error occurrence was fixed: "Fix bogus "permission denied" failures occurring on Windows due to attempts to fsync already-deleted files (Magnus, Tom)" I still can observe such erroneous behavior in the latest release of PostgreSQL: select version(); "PostgreSQL 8.2.3 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special)" Typical error message is the following: 2007-03-16 22:21:08 ERROR: could not open relation 16405/16406/2609: Permission denied It seems that it occurs when DDL operator is performed. This error occurs irrespective of option "fsync" value, though it seems that if "fsync=off" than the frequency error occurrence is less a little bit comparing to "fsync=on" case. All other parameters in file postgresql.conf were not changed. I have made a "clean" install of the latest release of PostgreSQL. OS: Windows XP Pro SP2 As I can suppose, the problem which was discussed in the "[HACKERS] Idea for fixing the Windows fsync problem" has not been fixed yet. Here are some typical error messages in files pg_log/*: - 2007-03-19 18:57:22 LOG: could not open temporary statistics file "global/pgstat.tmp": Permission denied 2007-03-19 18:58:28 NOTICE: Table does not exist: part_MsgRoot_(2000-01-01 01:00) 2007-03-19 18:58:28 CONTEXT: SQL statement "SELECT "andbDoPrepareView_sp"( $1 , $2 , $3 )" - 2007-03-19 19:08:39 ERROR: could not open relation 16405/16406/21745: Permission denied 2007-03-19 19:08:39 CONTEXT: SQL statement " CREATE UNIQUE INDEX "part_MsgPos2_(2007-01-01 02:00)_UTC_UID" ON "part_MsgPos2_(2007-01-01 02:00)" ( "UTC", "UID" ); " PL/pgSQL function "andbCreatePartitionsForGroup_sp" line 32 at execute statement - 2007-03-19 19:25:54 ERROR: could not open relation 16405/16406/22479: Permission denied 2007-03-19 19:25:54 CONTEXT: SQL statement "ALTER TABLE "part_MsgRoot_(2007-01-01 03:00)" ADD CHECK( "UTC" >= '2007-01-01 03:00:00' and "UTC" < '2007-01-01 04:00:00' )" - 2007-03-19 19:25:56 ERROR: could not open relation 16405/16406/22603: Permission denied 2007-03-19 19:25:56 CONTEXT: SQL statement " CREATE UNIQUE INDEX "part_MsgOther2_(2007-01-01 03:00)_UTC_UID" ON "part_MsgOther2_(2007-01-01 03:00)" ( "UTC", "UID" ); " PL/pgSQL function "andbCreatePartitionsForGroup_sp" line 32 at execute statement - 2007-03-20 17:21:46 ERROR: could not open relation 16405/16406/26881: Permission denied 2007-03-20 17:21:46 CONTEXT: SQL statement "ALTER TABLE "Billing" ADD CHECK( "UTC" IS NULL )" PL/pgSQL function "andbRegisterPartitionedTable_sp" line 6 at execute statement - Regards Sergey Zubkovsky
[BUGS] ERROR: tuple concurrently updated
Hello. Testing of the concurrent access to database objects leaded to the following error: ERROR: tuple concurrently updated SQL state: XX000 According to the "PostgreSQL Error Codes" table in the documentation, "XX000" is the PostgreSQL internal error code. How to reproduce such an error: 1. Create a table in some database and view: create table t1 ( id int ); create temp view v1 as select * from t1; 2. Concurrent access to table t1 is performed by 2 clients (further C1 and C2) particularly in this order: C1: begin; drop view v1; C2: drop table t1; C1: commit; And finally, transaction of the client C2 is terminated with this "expected" error. What's wrong?
Re: [BUGS] "Permission denied" failures occurring on Windows
It was Kaspersky antivirus with its on-fly "*:KAVICHS" NTFS-streams. Thanks. -Original Message- From: Dave Page [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 28, 2007 11:36 AM To: Magnus Hagander Cc: Zubkovsky, Sergey; pgsql-bugs@postgresql.org Subject: Re: [BUGS] "Permission denied" failures occurring on Windows Magnus Hagander wrote: > > The obvious question before we even think about anything else - any > antivirus, antispyware or any other third party software on the machine > that may be using a filter driver? Any idea how easy would it be to log the installed filter drivers at startup? If we can gather more info over the long term we could get a better idea of what products have iffy drivers. Regards Dave ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] ERROR: tuple concurrently updated
It seems that solution with a shared lock on t1 is working. Though in this case I have the following questions: 1. If the session in which v1 was created is terminated abnormally, then there is a chance of the initial situation iteration, because v1 is a temporary view. What about this? 2. If I use an advisory lock instead of LOCK TABLE then what is the sequence of the following implicit objects deallocation: advisory locks and temporary views? As far as I understand from your reply, there is an unresolved problem of concurrent access to the system catalog in PostgreSQL, which was noticed in case which I have described. I understand that I should try not to execute DLL operators in concurrent transactions. However I cannot avoid it in my case. What can you suggest to do in this case, taking into account that PostgreSQL does not provide necessary stability? The main problem here is how to make safely the deletion of the temporary view (v1) in one session, and deletion of tables which are pointed by this temporary view (v1) in another session. Thank you. -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 28, 2007 10:02 PM To: Zubkovsky, Sergey Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] ERROR: tuple concurrently updated "Zubkovsky, Sergey" <[EMAIL PROTECTED]> writes: > create table t1 ( id int ); > create temp view v1 as select * from t1; > C1: begin; drop view v1; > C2: drop table t1; > C1: commit; This seems a variant of the problem noted by Michael Fuhr some time ago: http://archives.postgresql.org/pgsql-hackers/2007-01/msg00937.php but I think it shows that the solution I proposed in that thread is still not adequate. To deal with the above, it seems like dropping v1 would have to acquire a shared lock on t1, thereby preventing the drop of t1 from starting until after v1 is safely gone. Or maybe have the drop of t1 recheck to see if v1 is still there after it has acquired lock on v1, but I'm afraid that might be too late to prevent an update conflict on the pg_depend row that both transactions want to delete. Ick. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #3328: initialization complex types with domain column
The following bug has been logged online: Bug reference: 3328 Logged by: Sergey Morgalev Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: windows xp, free bsd Description:initialization complex types with domain column Details: Hello. When user defined complex type with user defined DOMAIN with NOT NULL AND DEFAULT attrubute, postgres can't initialize variable in DECLARE section of PROCEDURE for example: -- create some DOMAIN CREATE DOMAIN my_domain AS numeric DEFAULT 0 NOT NULL; -- create complex type CREATE TYPE t_my_type AS ( int id, name vachar, value my_domain ) PostgreSQL 8.2.4 does not allow the declare variable with type 't_my_type' in a FUNCTION CREATE OR REPLACE FUNCTION m_function() RETURNS SETOF t_my_type AS $$ DECLARE _my_var t_my_type; --- skipped -- ERROR: domain my_domain does not allow null values CONTEXT: PL/pgSQL function "my_function" line 4 at block variables initialization Ok. will declare the '_my_var' variable with type 'RECORD' and initialize record in the FUNCTION body. Postgres will cast the record var to t_my_type and allow return SETOF. But. When FUNCTION accept argument with complex type, it is not possible. PostgreSQL can't cast record to user defined type. It is not possible use complex types with such domains in procedures. In previous version - 8.2.1 it's worked normaly. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #3396: strange error report for 'create domain ... default null'
The following bug has been logged online:
Bug reference: 3396
Logged by: Sergey Burladyan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.9
Operating system: CentOS release 5 (Final)
Description:strange error report for 'create domain ... default
null'
Details:
i try create domain with 'default null' value, but postgres say:
ERROR: cache lookup failed for type 0
without 'default null' it is work good.
seb=> select version();
version
PostgreSQL 8.1.9 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.1
20070105 (Red Hat 4.1.1-52)
(1 row)
Time: 1.160 ms
seb=> begin;
BEGIN
Time: 0.141 ms
seb=> CREATE DOMAIN qos_class_domain AS varchar(32) DEFAULT NULL CHECK
(VALUE IS NULL OR VALUE IN ('be', 'cir', 'cbr'));
ERROR: XX000: cache lookup failed for type 0
LOCATION: typeidTypeRelid, parse_type.c:347
seb=> ROLLBACK ;
ROLLBACK
Time: 0.098 ms
seb=>
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[BUGS] BUG #3494: may be Query Error: subplan does not executed
The following bug has been logged online:
Bug reference: 3494
Logged by: Sergey Burladyan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.9
Operating system: CentOS release 5 (Final)
Description:may be Query Error: subplan does not executed
Details:
i have query with join of two table and 'where' filter it result by subplan
which have references to join result, but this subplan not executed and
result is incorrect. This subplan also not exist in explain analyze output.
test schema:
create table test_1 ( name char(10), ku numeric(4) , ku_1 numeric(4) );
insert into test_1 (name,ku,ku_1) values ('Petrov', 1, 0);
insert into test_1 (name,ku,ku_1) values ('Ivanov', 2, 0);
insert into test_1 (name,ku,ku_1) values ('Sidorov', 3, 0);
create table test_2 (kh numeric(13), ku numeric(4) , d_s timestamp );
insert into test_2 (kh,ku,d_s) values (1, 1, '2007-01-01');
insert into test_2 (kh,ku,d_s) values (1, 2, '2007-01-01');
insert into test_2 (kh,ku,d_s) values (1, 3, '2007-01-01');
problem query:
select *
fromtest_1 mt1,
test_2 mt2
where mt2.kh = 1 and
mt2.ku between 1 and 100 and
mt1.ku = mt2.ku and
mt1.ku =(select min(t1.ku)
from test_1 t1,test_2 t2
where t1.ku_1 = mt1.ku_1 and
t2.kh = mt2.khand
t2.d_s = mt2.d_s and
t1.ku = t2.ku )
QUERY PLAN
-
Merge Join (cost=2.13..2.19 rows=3 width=60) (actual time=0.062..0.078
rows=3 loops=1)
Merge Cond: ("outer".ku = "inner".ku)
-> Sort (cost=1.05..1.06 rows=3 width=32) (actual time=0.026..0.029
rows=3 loops=1)
Sort Key: mt1.ku
-> Seq Scan on test_1 mt1 (cost=0.00..1.03 rows=3 width=32)
(actual time=0.007..0.011 rows=3 loops=1)
-> Sort (cost=1.08..1.08 rows=3 width=28) (actual time=0.028..0.030
rows=3 loops=1)
Sort Key: mt2.ku
-> Seq Scan on test_2 mt2 (cost=0.00..1.05 rows=3 width=28)
(actual time=0.011..0.018 rows=3 loops=1)
Filter: ((kh = 1::numeric) AND (ku >= 1::numeric) AND (ku <=
100::numeric))
But, when i comment out some 'where' condition in subplan because it always
true (i think) - subplan show up and query work ok:
select*
fromtest_1 mt1,
test_2 mt2
where mt2.kh = 1 and
mt2.ku between 1 and 100 and
mt1.ku = mt2.ku and
mt1.ku =(select min(t1.ku)
from test_1 t1,test_2 t2
where /* t1.ku_1 = mt1.ku_1 and */
t2.kh = mt2.khand
t2.d_s = mt2.d_s and
t1.ku = t2.ku )
QUERY PLAN
-
---
Nested Loop (cost=0.00..8.74 rows=1 width=60) (actual time=0.125..0.248
rows=1 loops=1)
Join Filter: ("inner".ku = "outer".ku)
-> Seq Scan on test_2 mt2 (cost=0.00..7.67 rows=1 width=28) (actual
time=0.114..0.228 rows=1 loops=1)
Filter: ((kh = 1::numeric) AND (ku >= 1::numeric) AND (ku <=
100::numeric) AND ((subplan) = ku))
SubPlan
-> Aggregate (cost=2.19..2.20 rows=1 width=10) (actual
time=0.063..0.064 rows=1 loops=3)
-> Merge Join (cost=2.12..2.18 rows=3 width=10) (actual
time=0.039..0.054 rows=3 loops=3)
Merge Cond: ("outer".ku = "inner".ku)
-> Sort (cost=1.05..1.06 rows=3 width=10) (actual
time=0.009..0.011 rows=3 loops=3)
Sort Key: t1.ku
-> Seq Scan on test_1 t1 (cost=0.00..1.03
rows=3 width=10) (actual time=0.004..0.009 rows=3 loops=1)
-> Sort (cost=1.07..1.08 rows=3 width=10) (actual
time=0.024..0.026 rows=3 loops=3)
Sort Key: t2.ku
-> Seq Scan on test_2 t2 (cost=0.00..1.04
rows=3 width=10) (actual time=0.006..0.013 rows=3 loops=3)
Filter: ((kh = $0) AND (d_s = $1))
-> Seq Scan on test_1 mt1 (cost=0.00..1.03 rows=3 width=32) (actual
time=0.003..0.006 rows=3 loops=1)
i am not sure, is this my incompetence or may be problem in planer ?
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[BUGS] pg_dump and password required
Hello! I have Postgres configured so it requires password to access DB (in pg_hba.conf). The problem is that I want to set up an automated backup with pg_dump, but it asks for password interactively, rather then accept password from either command-line option or from some config-file (e.g. ~/.psqlrc) The workaround would be to disable password requirement, but this is a security risk I want to avoid. Why no to add an option --password="" to command-line options of pg_dump? -- Sincerely, Sergey Litvinenko - [EMAIL PROTECTED] icq#: 34161555 http://www.rsu.ru/~sergey/ ---(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] Internal Error on 'vacuum full'
Hi, After dropping some tables in my PG 8.3 DB I tried to execute 'vacuum full' command and got the error: ERROR: invalid memory alloc request size 4294967280 SQL state: XX000 Up to now the error has not reproduced once again. select version(); "PostgreSQL 8.3.0, compiled by Visual C++ build 1400" --- Sergey Zubkovsky
[BUGS] bug or not bug, xmlvalidate(xml, text) can read and show one line from file
Hi, all
seb=> select version();
version
PostgreSQL 8.3.0 on x86_64-pc-linux-gnu, compiled by GCC
x86_64-pc-linux-gnu-gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2)
xmlvalidate(xml, text) trying to read from file and if it is not correct -
notice error with first readed line. it is ok and good, but xmlvalidate can
read from _any_ file what DB process can access for read.
for example:
seb=> select xmlvalidate(xml('testmessage in
b'), '/etc/passwd');
ERROR: could not load DTD
ПОДРОБНО: /etc/passwd:1: parser error : Content error in the external subset
root:x:0:0:root:/root:/bin/bash
^
seb=> select xmlvalidate(xml('testmessage in
b'), '../data/postmaster.opts');
ERROR: could not load DTD
ПОДРОБНО: ../data/postmaster.opts:1: parser error : Content error in the
external subset
/usr/lib64/postgresql-8.3/bin/postgres -D /var/lib/postgresql/8.3/data --silent-
^
first line from private server ssl key :)
seb=> select xmlvalidate(xml('testmessage in
b'), '../data/server.key');
ERROR: could not load DTD
ПОДРОБНО: ../data/server.key:1: parser error : Content error in the external
subset
-BEGIN RSA PRIVATE KEY-
^
i don't know is this bug or security issue or not...
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[BUGS] 8.3 can't convert cyrillic text from 'iso-8859-5' to other cyrillic 8-bit encoding
Hi, all !
I can't convert with convert(bytea, name, name)::bytea from 'iso-8859-5'
to 'windows-1251' or any other cyrillic 8-bit encoding.
seb=> show client_encoding ;
client_encoding
-
UTF8
seb=> show server_encoding;
server_encoding
-
UTF8
seb=> select version();
version
PostgreSQL 8.3.0 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.3 (Debian
4.2.3-1)
lc_collate | ru_RU.UTF-8
lc_ctype| ru_RU.UTF-8
lc_messages | ru_RU.UTF-8
lc_monetary | ru_RU.UTF-8
lc_numeric | ru_RU.UTF-8
lc_time | ru_RU.UTF-8
seb=> select
convert(convert('абвгдеёжзийклмнопрстуфхцчшщъыьэюяАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ',
'utf-8', 'iso-8859-5'), 'iso-8859-5', 'windows-1251');
ERROR: character 0xf1 of encoding "ISO_8859_5" has no equivalent
in "MULE_INTERNAL"
At first - i am convert my console locale encoding (ru_RU.UTF-8) to iso-8859-5
(cyrillic 8-bit character encoding) and second convert is for show problem.
windows-1251 - is other cyrillic 8-bit character encoding, convert to koi8-r
also not work.
i am write output of convert(..., 'utf-8', 'iso-8859-5') into file and read it
with: iconv -f iso-8859-5 -- all chars readed ok. (see progs in attach)
convert(..., 'iso-8859-5', 'utf-8') looking good, i am check it like this:
seb=> set standard_conforming_strings TO on; --- do not escape bytea
SET
seb=> select
convert('\320\321\322\323\324\325\361\326\327\330\331\332\333\334\335\336\337\340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357\260\261\262\263\264\265\241\266\267\270\271\272\273\274\275\276\277\300\301\302\303\304\305\306\307\310\311\312\313\314\315\316\317',
'iso-8859-5', 'utf-8');
convert
--
\320\260\320\261\320\262\320\263\320\264\320\265\321\221\320\266\320\267\320\270\320\271\320\272\320\273\320\274\320\275\320\276\320\277\321\200\321\201\321\202\321\203\321\204\321\205\321\206\321\207\321\210\321\211\321\212\321\213\321\214\321\215\321\216\321\217\320\220\320\221\320\222\320\223\320\224\320\225\320\201\320\226\320\227\320\230\320\231\320\232\320\233\320\234\320\235\320\236\320\237\320\240\320\241\320\242\320\243\320\244\320\245\320\246\320\247\320\250\320\251\320\252\320\253\320\254\320\255\320\256\320\257
(1 запись)
seb=> set standard_conforming_strings TO off; --- now we must escaping bytea
for show text
SET
seb=> select
E'\320\260\320\261\320\262\320\263\320\264\320\265\321\221\320\266\320\267\320\270\320\271\320\272\320\273\320\274\320\275\320\276\320\277\321\200\321\201\321\202\321\203\321\204\321\205\321\206\321\207\321\210\321\211\321\212\321\213\321\214\321\215\321\216\321\217\320\220\320\221\320\222\320\223\320\224\320\225\320\201\320\226\320\227\320\230\320\231\320\232\320\233\320\234\320\235\320\236\320\237\320\240\320\241\320\242\320\243\320\244\320\245\320\246\320\247\320\250\320\251\320\252\320\253\320\254\320\255\320\256\320\257';
?column?
абвгдеёжзийклмнопрстуфхцчшщъыьэюяАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ
(1 запись)
it os ok.
text string parameter is russian alphabet from first letter to last, lower
case, and from first letter to last, UPPER case
may be i am doing something wrong ?
---
#include
#include
using namespace std;
int main()
{
/*
seb=> select convert('абвгдеёжзийклмнопрстуфхцчшщъыьэюяАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ', 'utf-8', 'iso-8859-5');
convert
Re: [BUGS] 8.3 can't convert cyrillic text from 'iso-8859-5' to other cyrillic 8-bit encoding
Hi, all ! i'm find the problem. src/backend/utils/mb/conversion_procs/cyrillic_and_mic/cyrillic_and_mic.c does not have cyrillic letter 'IO' in ISO-8859-5 to mule internal code translation table (function iso2mic(const unsigned char *l, unsigned char *p, int len)). this is bug, because it is widely used and it is main letter like A, B or C in english :) and it is exist in all russian cyrillic's encoding (koi8-r, iso-8859-5, windows-1251, cp866). for example, in russian, words 'all', 'hedgehog', 'Christmas-tree' and many other must be written with it. here is the patch for add it to ISO-8859-5 to mule internal code translation table. i am don't know is this ok and do not brake any internal rule or code ? By the way, as i can understand you are using koi8-r encoding for internal representation of cyrillic charsets - this is have also another problem. the second "widely" used char is NUMERO SIGN (many accountants and managers use it :) in cyrillic windows world) and it is exist in windows-1251, cp866 and iso-8859-5 encoding, but not in koi8-r... --- *** cyrillic_and_mic.c.org 2008-03-18 02:16:35.0 +0300 --- cyrillic_and_mic.c 2008-03-18 02:19:16.0 +0300 *** *** 483,489 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ! 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xe1, 0xe2, 0xf7, 0xe7, 0xe4, 0xe5, 0xf6, 0xfa, 0xe9, 0xea, 0xeb, 0xec, 0xed, 0xee, 0xef, 0xf0, --- 483,489 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ! 0x00, 0xb3, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xe1, 0xe2, 0xf7, 0xe7, 0xe4, 0xe5, 0xf6, 0xfa, 0xe9, 0xea, 0xeb, 0xec, 0xed, 0xee, 0xef, 0xf0, *** *** 493,499 0xc9, 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf, 0xd0, 0xd2, 0xd3, 0xd4, 0xd5, 0xc6, 0xc8, 0xc3, 0xde, 0xdb, 0xdd, 0xdf, 0xd9, 0xd8, 0xdc, 0xc0, 0xd1, ! 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; --- 493,499 0xc9, 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf, 0xd0, 0xd2, 0xd3, 0xd4, 0xd5, 0xc6, 0xc8, 0xc3, 0xde, 0xdb, 0xdd, 0xdf, 0xd9, 0xd8, 0xdc, 0xc0, 0xd1, ! 0x00, 0xa3, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; -- 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 can't convert cyrillic text from 'iso-8859-5' to other cyrillic 8-bit encoding
Thursday 20 March 2008 01:16:34 Heikki Linnakangas:
Thanks for answer, Heikki !
> You'd need to modify the mic->ISO-8859-5 translation table as well, for
> converting in the other direction.
oops, i have not thought about it %)
> Here's a patch that does the conversion in the other direction as well.
> As I'm not too familiar with cyrillic, can you double-check that this
> works? I tested it using the convert() function between different
> encodings, and it seems ok to me.
yes, i test it with function like this and it work now :)
create or replace function test_convert() returns setof record as $$
declare
--- russian alphabet, 33 upper and 33 lower letters in utf-8 encoding
r bytea default
E'\320\260\320\261\320\262\320\263\320\264\320\265\321\221\320\266\320\267\320\270\320\271\320\272\320\273\320\274\320\275\320\276\320\277\321\200\321\201\321\202\321\203\321\204\321\205\321\206\321\207\321\210\321\211\321\212\321\213\321\214\321\215\321\216\321\217\320\220\320\221\320\222\320\223\320\224\320\225\320\201\320\226\320\227\320\230\320\231\320\232\320\233\320\234\320\235\320\236\320\237\320\240\320\241\320\242\320\243\320\244\320\245\320\246\320\247\320\250\320\251\320\252\320\253\320\254\320\255\320\256\320\257';
s bytea; --- converted to result
t bytea; --- converted back result
res record;
begin
raise notice 'russian ABC: "%"', encode(r, 'escape');
s := convert(r, 'utf-8', 'iso-8859-5');
t := convert(s, 'iso-8859-5', 'windows-1251'); t :=
convert(t, 'windows-1251', 'utf-8');
if t != r then
raise exception 'iso-8859-5, windows-1251 | t != r';
end if;
res := row('iso-8859-5, windows-1251'::text, encode(
convert(convert(s, 'iso-8859-5', 'windows-1251'), 'windows-1251', 'utf-8')
, 'escape')::text
);
return next res;
[...skip...]
seb=# select * from test_convert() as (conv text, res text);
NOTICE: russian ABC: "абвгдеёжз..."
conv|res
+---
iso-8859-5, windows-1251 | абвгдеёжз...
iso-8859-5, windows-866| абвгдеёжз...
iso-8859-5, koi8-r | абвгдеёжз...
iso-8859-5, iso-8859-5 | абвгдеёжз...
windows-866, windows-1251 | абвгдеёжз...
windows-866, iso-8859-5| абвгдеёжз...
windows-866, koi8-r| абвгдеёжз...
windows-866, windows-866 | абвгдеёжз...
windows-1251, windows-866 | абвгдеёжз...
windows-1251, iso-8859-5 | абвгдеёжз...
windows-1251, koi8-r | абвгдеёжз...
windows-1251, windows-1251 | абвгдеёжз...
koi8-r, windows-866| абвгдеёжз...
koi8-r, iso-8859-5 | абвгдеёжз...
koi8-r, windows-1251 | абвгдеёжз...
koi8-r, koi8-r | абвгдеёжз...
(16 rows)
> Hmm. We use KOI8-R (or rather, MULE_INTERNAL with KOI8-R ) as an
> intermediate encoding, because there's no direct conversion table
> between ISO-8859-5 and the other cyrillic encodings. Ideally there would
> be. Another possibility would be to use UTF-8 as the intermediate
> encoding; that'd probably be much slower, but UTF-8 should have all the
> characters needed.
I think that UTF-8 is too complex for translate 8-bit charset to another 8-bit
charset, but other solution is many many translate tables... hard question %)
> Is there any other characters like "YO" that are missing, that exist in
> all the encodings?
if we say about alphabet letters, the answer is - No, only "YO" was missing.
if we say about any character, there is 'NO-BREAK SPACE' (U+00A0) it exist in
1251, 866, koi8-r and iso but i do not think that it widely used...
> Looking at the character set table for KOI8-R, it
> looks like the "YO" is in an odd place in the table, compared to all
> other cyrillic characters. Perhaps that's why it was missed.
Yes, i understand. russian character sets always been a challenge for all
programmers :) it are at least five, and it are all different
Thanks for patch, Heikki !
---
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] can't delete record from second table in rules of view with join select
Hello, all From sql.ru forum: not important, is it one rule like: create rule v_del as on delete to v do instead ( delete from o1 where id = old.o1_id; delete from o2 where id = old.o2_id; ); or split into two rule like: create rule v_del1 as on delete to v do instead ( delete from o1 where id = old.o1_id; ); create rule v_del2 as on delete to v do instead ( delete from o2 where id = old.o2_id; ); delete from second table (o2) do not delete anything. test case: begin; select version(); create table o1 (id int, val text); create table o2 (id int, val text); create view v as select o1.id as o1_id, o1.val as o1_val, o2.id as o2_id, o2.val as o2_val from o1, o2 where o1.id=o2.id; create rule v_del as on delete to v do instead ( delete from o1 where id = old.o1_id; delete from o2 where id = old.o2_id; ); -- create rule v_del1 as on delete to v do instead ( --delete from o1 where id = old.o1_id; -- ); -- create rule v_del2 as on delete to v do instead ( --delete from o2 where id = old.o2_id; -- ); insert into o1 values (1, 'o1 1'), (2, 'o1 2'), (3, 'o1 3'); insert into o2 values (1, 'o2 1'), (2, 'o2 2'), (3, 'o2 3'); select * from v; delete from v where o1_id = 1; explain analyze delete from v where o2_id = 2; select * from v; select * from o1; select * from o2; rollback; === output === version PostgreSQL 8.3.0 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.3 (Debian 4.2.3-1) --- select * from v; o1_id | o1_val | o2_id | o2_val ---++---+ 1 | o1 1 | 1 | o2 1 2 | o1 2 | 2 | o2 2 3 | o1 3 | 3 | o2 3 (3 rows) --- delete from v where o1_id = 1; seb=> DELETE 0 --- explain analyze delete from v where o2_id = 2; QUERY PLAN --- Nested Loop (cost=50.76..81.18 rows=216 width=6) (actual time=0.040..0.050 rows=1 loops=1) -> Nested Loop (cost=25.38..51.48 rows=36 width=14) (actual time=0.030..0.034 rows=1 loops=1) -> Seq Scan on o1 (cost=0.00..25.38 rows=6 width=10) (actual time=0.014..0.015 rows=1 loops=1) Filter: (id = 2) -> Materialize (cost=25.38..25.44 rows=6 width=4) (actual time=0.012..0.014 rows=1 loops=1) -> Seq Scan on o2 (cost=0.00..25.38 rows=6 width=4) (actual time=0.007..0.008 rows=1 loops=1) Filter: (id = 2) -> Materialize (cost=25.38..25.44 rows=6 width=4) (actual time=0.007..0.010 rows=1 loops=1) -> Seq Scan on o1 (cost=0.00..25.38 rows=6 width=4) (actual time=0.005..0.008 rows=1 loops=1) Filter: (id = 2) Total runtime: 0.135 ms Nested Loop (cost=50.76..81.18 rows=216 width=6) (actual time=0.034..0.034 rows=0 loops=1) -> Nested Loop (cost=25.38..51.48 rows=36 width=10) (actual time=0.019..0.023 rows=1 loops=1) -> Seq Scan on o2 (cost=0.00..25.38 rows=6 width=10) (actual time=0.008..0.009 rows=1 loops=1) Filter: (id = 2) -> Materialize (cost=25.38..25.44 rows=6 width=4) (actual time=0.009..0.011 rows=1 loops=1) -> Seq Scan on o2 (cost=0.00..25.38 rows=6 width=4) (actual time=0.006..0.007 rows=1 loops=1) Filter: (id = 2) -> Materialize (cost=25.38..25.44 rows=6 width=4) (actual time=0.008..0.008 rows=0 loops=1) -> Seq Scan on o1 (cost=0.00..25.38 rows=6 width=4) (actual time=0.007..0.007 rows=0 loops=1) Filter: (id = 2) Total runtime: 0.083 ms (23 rows) --- select * from v; o1_id | o1_val | o2_id | o2_val ---++---+ 3 | o1 3 | 3 | o2 3 (1 запись) --- select * from o1; (all correctly deleted) id | val +-- 3 | o1 3 (1 запись) --- select * from o2; (no one deleted) id | val +-- 1 | o2 1 2 | o2 2 3 | o2 3 (3 rows) seb=> ROLLBACK --- -- 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] can't delete record from second table in rules of view with join select
Hello, all > not important, is it one rule like: > create rule v_del as on delete to v do instead ( >delete from o1 where id = old.o1_id; >delete from o2 where id = old.o2_id; > ); > > or split into two rule like: > create rule v_del1 as on delete to v do instead ( >delete from o1 where id = old.o1_id; > ); > create rule v_del2 as on delete to v do instead ( >delete from o2 where id = old.o2_id; > ); Sorry, after thinking some time about this problem now i may be understand what going on there... %) When first rule was exec - no OLD row anymore in "v" view, nothing will be joined and in second rule OLD value is empty... so my question is changed to: is this expected behavior or a bug ? %) --- -- 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 report for Postgresql 8.0-beta1 for WINDOWS.
Hello pgsql-bugs, The bug description is as follows: Then server with running postmaster unexpectedly shut down, server cannot be started next time. I've found that manual starting of that service also unsuccessful. I investigated the bug, and found that the .pid file exists at PGDATA folder. So I decided to delete that file, and try to start service. It works! Probably pg_ctl looks for .pid file, and if it exists it supposes that the service is already started. In fact it's wrong. How to repeat the bug: 1. Stop service 2. Create postmaster.pid at PGDATA 3. Try to start service. It will refuse. Suggested solution: Change service detection logic. May be not just looking for the pid file, but parsing it and finding the service process itself and testing it for existance. Sorry if it is already fixed in new version. -- Best regards, Sergey mailto:[EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] BUG #1471: Corrected e-mail address - bug 1470
The following bug has been logged online: Bug reference: 1471 Logged by: Sergey Koshcheyev Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.6 Operating system: Linux (Debian) Description:Corrected e-mail address - bug 1470 Details: Sorry for this dummy report, but I found that I put a wrong e-mail address while reporting bug 1470 and can't find any way to change it through your site. Could you please change it? ([EMAIL PROTECTED] -> [EMAIL PROTECTED]). ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #1470: Boolean expression index not used when it could be
The following bug has been logged online: Bug reference: 1470 Logged by: Sergey Koshcheyev Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.6 Operating system: Linux (Debian) Description:Boolean expression index not used when it could be Details: I'm trying to optimize "is null" queries, since PgSQL doesn't index null values. I have found that creating an expression index on (column is null) could work, but it doesn't get used unless the index expression is part of a comparison. Could this be improved, so that (a boolean expression) is taken as equivalent to (a boolean expression = true)? Here's an example: office=> create table tbl1 (abc int); CREATE TABLE office=> create index tbl1_abc on tbl1 ((abc is null)); CREATE INDEX office=> explain select * from tbl1 where (abc is null) = true; QUERY PLAN -- Index Scan using tbl1_abc on tbl1 (cost=0.00..17.07 rows=6 width=4) Index Cond: ((abc IS NULL) = true) (2 rows) office=> explain select * from tbl1 where (abc is null); QUERY PLAN - Seq Scan on tbl1 (cost=0.00..20.00 rows=6 width=4) Filter: (abc IS NULL) (2 rows) I would like the second select to pick up the index too. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] BUG #1510: Indexes on boolean fields
The following bug has been logged online: Bug reference: 1510 Logged by: Sergey Koshcheyev Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.7 Operating system: Debian Linux Description:Indexes on boolean fields Details: Hi, this is an addition to my bug report #1470. I have found that if I have a boolean column and create an index on it, it doesn't get picked up for conditions like "WHERE column" or "WHERE NOT column", only "WHERE column = true" or "WHERE column = false". Do you consider this worth fixing? I believe that #1470 would then be fixed also, and it would be very useful for me. Here's a complete listing of what I did, the two last EXPLAINs show the problem. office=> create table booltest (id serial not null primary key, b boolean); NOTICE: CREATE TABLE will create implicit sequence "booltest_id_seq" for "serial" column "booltest.id" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "booltest_pkey" for table "booltest" CREATE TABLE (insert 57336 values into booltest(b), 6211 of them are false - based on some real data) office=> create index booltest_b on booltest (b); CREATE INDEX office=> analyze booltest; ANALYZE office=> explain select * from booltest where b = true; QUERY PLAN --- Seq Scan on booltest (cost=0.00..1001.10 rows=51776 width=5) Filter: (b = true) (2 rows) office=> explain select * from booltest where b = false; QUERY PLAN Index Scan using booltest_b on booltest (cost=0.00..586.29 rows=5753 width=5) Index Cond: (b = false) (2 rows) office=> explain select * from booltest where not b; QUERY PLAN - Seq Scan on booltest (cost=0.00..857.28 rows=5753 width=5) Filter: (NOT b) (2 rows) office=> explain select * from booltest where b = false; QUERY PLAN Index Scan using booltest_b on booltest (cost=0.00..586.29 rows=5753 width=5) Index Cond: (b = false) (2 rows) Thanks, Sergey. P.S. I can't write to psql-bugs, even though I am subscribed - my messages don't reach the list (they don't appear on Gmane). Have I been banned? :) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1470: Boolean expression index not used when it could be
Tom Lane wrote: "Sergey Koshcheyev" <[EMAIL PROTECTED]> writes: I'm trying to optimize "is null" queries, since PgSQL doesn't index null values. I have found that creating an expression index on (column is null) could work, but it doesn't get used unless the index expression is part of a comparison. Could this be improved, so that (a boolean expression) is taken as equivalent to (a boolean expression = true)? You would be better off to use a partial index: create index tbl1_abc on tbl1 (somecol) where abc is null; The advantage of this is that not only do you get the is-null filter, but you may be able to filter on some other column(s) at the same time. For instance if you commonly query select ... from tbl1 where abc is null and def > 42 then making "somecol" be "def" would be a winner. regards, tom lane Well, I have tried playing with indexes, but it's hard to define the right indexes for the query, even if NULLs are not involved. One more example (based on real-world data, except I renamed the fields and the table): office=> explain analyze select * from table where (field1 = 0) AND ((field2 IS NULL) OR (field3 = 0)); QUERY PLAN (a line of dashes stripped to allow wrapping) Seq Scan on table (cost=0.00..2103.92 rows=3091 width=174) (actual time=0.176..2413.078 rows=15 loops=1) Filter: ((field1 = 0) AND ((field2 IS NULL) OR (field3 = 0))) Total runtime: 2413.349 ms (3 rows) - Note that the estimate is way off, and raising statistics actually makes it even worse. There is an index defined on (field1), but it doesn't get picked up (probably because lots of rows have field1 equal 0). I have tried to index (field1) where ((field2 IS NULL) OR (field3 = 0)), but it doesn't get picked up either. office=> explain analyze select * from table where (field1 = 0) AND ((field2 IS NULL) OR (field3 = 0)) = true; QUERY PLAN (a line of dashes stripped to allow wrapping) Index Scan using table_index on table (cost=0.00..1041.36 rows=289 width=174) (actual time=89.689..100.895 rows=15 loops=1) Index Cond: (((field1 = 0) AND ((field2 IS NULL) OR (field3 = 0 = true) Total runtime: 101.580 ms (3 rows) - This query runs much faster, but requires the "= true". Would the change I suggested (adding the "= true" automatically) be difficult to implement? We have about 10-20 various queries defined using such conditions, and they are run frequently, so it would help us a lot. Or are there any other ways to make it run fast which would not require me to change the database schema? Thanks, Sergey P.S. I know that this stuff belongs more to psql-performance list, I'm writing it all here just to justify my request. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] BUG #2293: primary key and cyrillic
The following bug has been logged online: Bug reference: 2293 Logged by: Sergey Rosenfeld Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: Debian GNU/Linux (sid) Description:primary key and cyrillic Details: postgres:~$ /usr/lib/postgresql/8.1/bin/pg_controldata /var/lib/postgresql/8.1/main <...skipped cyrillic koi8-r output ...> LC_COLLATE: ru_RU.koi8r LC_CTYPE: ru_RU.koi8r postmaster works in same locale environment postgres:~$ psql Welcome to psql 8.1.3, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# select version(); version -- PostgreSQL 8.1.3 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9) (1 запиÑÑ) postgres=# show server_encoding; server_encoding - KOI8 (1 запиÑÑ) postgres=# show client_encoding; client_encoding - KOI8 (1 запиÑÑ) postgres=# create table test( s varchar(20) primary key ); NOTICE: CREATE TABLE / PRIMARY KEY ÑоздаÑÑ Ð¿Ð¾Ð´ÑазÑмеваемÑй Ð¸Ð½Ð´ÐµÐºÑ "test_pkey" Ð´Ð»Ñ ÑаблиÑÑ "test" CREATE TABLE postgres=# \d test ТаблиÑа "public.test" Ðолонка | Тип | ÐодиÑикаÑоÑÑ -+---+-- s | character varying(20) | not null ÐндекÑÑ: "test_pkey" PRIMARY KEY, btree (s) postgres=# insert into test values( 'ÑÑва ÑÑва' ); INSERT 0 1 postgres=# insert into test values( 'ÑÑва ÑÑва' ); INSERT 0 1 postgres=# select * from test; s --- ÑÑва ÑÑва ÑÑва ÑÑва (запиÑей: 2) What about PRIMARY KEY? If i use ascii symbols, all works fine: postgres=# insert into test values( 'asdf asdf' ); INSERT 0 1 postgres=# insert into test values( 'asdf asdf' ); ERROR: повÑоÑнÑй клÑÑ Ð½Ð°ÑÑÑÐ°ÐµÑ ÐºÐ¾Ð½ÑÑÑÐµÐ¹Ð½Ñ UNIQUE "test_pkey" ---(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] psql: cannot run DISCARD ALL with AUTOCOMMIT = 'off'
seb=> select version(); version -- PostgreSQL 8.4.4 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.4.real (Debian 4.4.4-7) 4.4.4, 64-bit (1 row) Time: 0,074 ms seb=> abort; ROLLBACK Time: 0,086 ms seb=> DISCARD ALL ; ERROR: DISCARD ALL cannot run inside a transaction block DISCARD is not mentioned anywhere in the src/bin/psql/common.c in command_no_begin(const char *query) function. I don't know, may be this is expected behavior. -- Sergey Burladyan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
problem with glibc strerror messages translation (was: [BUGS] Could not open file pg_xlog/000000010....)
Tom Lane writes:
> Victor writes:
> > Oct 12 17:53:25 localhost postgres[26997]: [1753-1] PANIC: could not
> > open file "pg_xlog/00010007" (log file 0, segment
> > 7):
>
> Hm, where's the rest of that error message? You should certainly not
> have gotten just question-marks there.
IMHO you can receive question-marks here if lc_messages in postgresql.conf
do not match with locale from environment at server start, for example:
correctly translated and displayed:
$ LANG=ru_RU.UTF-8 ../bin/postgres -D d -k`pwd`/s
2010-10-13 05:34:39 MSD 14796 4cb50caf.39cc FATAL: XX000: could not create
shared memory segment: Недопустимый аргумент
incorrect, question-marks only:
$ LANG=C ../bin/postgres -D d -k`pwd`/s
2010-10-13 05:34:54 MSD 14798 4cb50cbd.39ce FATAL: XX000: could not create
shared memory segment:
error message received from function strerror(). It use gettext (in glibc) for
messages translation.
man gettext say this:
In both cases, the functions also use the LC_CTYPE locale facet in order to
convert the translated message from the translator's codeset to the current
locale's codeset, unless overridden by a prior call to the
bind_textdomain_codeset function.
but when postgres starting, it set LC_CTYPE to current locale (I used gdb for
monitoring):
$ LANG=C gdb --args ../bin/postgres -D d -k`pwd`/s
(gdb) break setlocale
Breakpoint 1 at 0x453118
(gdb) commands
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>p {"LC_CTYPE ", "LC_NUMERIC ", "LC_TIME ", "LC_COLLATE
> ", "LC_MONETARY ", "LC_MESSAGES ", "LC_ALL ",
>"LC_PAPER ", "LC_NAME ", "LC_ADDRESS ", "LC_TELEPHONE
> ", "LC_MEASUREMENT ", "LC_IDENTIFICATION"}[category]
>c
>end
(gdb) set pagination off
(gdb) r
Starting program: /home/seb/inst/pg-dev/bin/postgres -D d
-k/home/seb/inst/pg-dev/var/s
Breakpoint 1, *__GI_setlocale (category=3, locale=0x7ff627 "") at
setlocale.c:199
199 setlocale.c: No such file or directory.
in setlocale.c
$1 = "LC_COLLATE "
Breakpoint 1, *__GI_setlocale (category=0, locale=0x7ff627 "") at
setlocale.c:199
199 in setlocale.c
$2 = "LC_CTYPE "
Breakpoint 1, *__GI_setlocale (category=5, locale=0x7ff627 "") at
setlocale.c:199
199 in setlocale.c
$3 = "LC_MESSAGES "
. . .
Breakpoint 1, *__GI_setlocale (category=5, locale=0xb31e10 "ru_RU.UTF-8") at
setlocale.c:199
199 in setlocale.c
$29 = "LC_MESSAGES "
so, if current environment do not match with lc_messages in postgresql.conf
- glibc cannot translate error message.
simple test program in attachment
#include
#include
#include
#include
#include
/*
* http://sourceware.org/git/?p=glibc.git;a=blob;f=string/_strerror.c
* http://sourceware.org/git/?p=glibc.git;a=blob;f=include/libintl.h
*
* man gettext
*
* In both cases, the functions also use the LC_CTYPE locale facet in order to
* convert the translated message from the translator's codeset to the current
* locale's codeset, unless overridden by a prior call to the
* bind_textdomain_codeset function.
*
*/
int main()
{
printf("LC_MESSAGES: %s\n", setlocale(LC_MESSAGES, "ru_RU.UTF-8"));
/* postgres do this at starting */
printf("LC_CTYPE: %s\n", setlocale(LC_CTYPE, ""));
/* can be fixed like this, but _libc_intl_domainname is private :( */
//printf("bind_textdomain_codeset: %s\n", bind_textdomain_codeset(/*_libc_intl_domainname*/"libc", "UTF-8"));
printf("msg: %s\n", strerror(22));
return 0;
}
correct:
$ ./a.out
LC_MESSAGES: ru_RU.UTF-8
LC_CTYPE: ru_RU.UTF-8
msg: Недопустимый аргумент
incorrect:
$ LANG=C ./a.out
LC_MESSAGES: ru_RU.UTF-8
LC_CTYPE: C
msg:
--
Sergey Burladyan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: BUG #5807: psql fails to launch with "Cannot read termcap database; using dumb terminal settings. Aborted"
On Jan 7, 1:32 pm, dp...@pgadmin.org (Dave Page) wrote: > On Fri, Jan 7, 2011 at 5:52 AM, Gabe Nell wrote: > >> If you install libtermcap then it will start working good. We have > >> tested it at our end. > > > Thanks Dharmendra, however in Ubuntu there is no package called > > libtermcap, though it has been suggested that the libncurses5-dev > > package provides this [1]. However I tried this and I still get the > > same error. Do you know the exact Ubuntu package that I need to > > install? > > Apparently my colleague downloaded and installed a tarball of GNU > termcap 1.3.1. > > I'm still not clear how this passed our internal testing though; I'm > guessing the QA test VMs do have some package on them which includes > termcap. Continuing the investigation... > > -- > Dave Page > Blog:http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK:http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > -- > Sent via pgsql-bugs mailing list (pgsql-b...@postgresql.org) > To make changes to your > subscription:http://www.postgresql.org/mailpref/pgsql-bugs Hi all. I have the same problem today was to install and create db in PSQL program in PostgreSQL 9.0.2 (Ubuntu 10.10 (32bit)). I solved it by using this command: LD_PRELOAD = /lib/libreadline.so.5 ./psql -- 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] sort order (ORDER BY) hu_HU.UTF-8 locale with UTF-8 encoding is not working correctly on FreeBSD
Adam PAPAI writes: > FreeBSD titanium 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 > UTC 2010 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > Tested PgSQL versions are: 8.4 and 9.0.3 (fresh install using ports) Did you try ICU patch? IMHO it can help with your problem. But i am not sure how it is stable. # cd /usr/ports/databases/postgresql84-server # make config ┌┐ │ Options for postgresql-server 8.4.5_2 │ │ ┌┐ │ │ │[X] NLS Use internationalized messages│ │ │ │[ ] PAM Build with PAM support (server only) │ │ │ │[ ] LDAP Build with LDAP authentication support│ │ │ │[ ] MIT_KRB5 Build with MIT's kerberos support │ │ │ │[ ] HEIMDAL_KRB5 Builds with Heimdal kerberos support │ │ │ │[ ] OPTIMIZED_CFLAGS Builds with compiler optimizations (-O3) │ │ │ │[X] XML Build with XML data type (server) │ │ │ │[X] TZDATAUse internal timezone database (server) │ │ │ │[ ] DEBUG Builds with debugging symbols │ │ │ │[X] GSSAPIBUild with GSSAPI support │ │ ==>│ │[ ] ICU Use ICU for unicode collation (server)│ │ │ │[X] INTDATE Builds with 64-bit date/time type (server)│ │ │ ││ │ │ ││ │ │ ││ │ ├─└┘─┤ │ [ OK ] Cancel│ └────────┘ -- Sergey Burladyan -- 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 #5900: Coredump on executing query
The following bug has been logged online:
Bug reference: 5900
Logged by: Sergey Aleynikov
Email address: sergey.aleyni...@gmail.com
PostgreSQL version: 8.4.1
Operating system: FreeBSD 7.3-STABLE amd64
Description:Coredump on executing query
Details:
I've a setup with 'auto_explain' enabled:
shared_preload_libraries = 'auto_explain'
custom_variable_classes = 'auto_explain'
auto_explain.log_min_duration = '3s'
auto_explain.log_nested_statements = true
Yesterday i've got a non-repeatable database server crash with following
messages in server log:
Feb 24 17:44:25 sigeon postgres[91789]: [5-28]
-> Index Scan using ind_log_1573_reversed on logs_1573 logs
(cost=0.00..
Feb 24 17:44:25 sigeon postgres[91789]: [5-29]
Index Cond: (opcode = 2302)
Feb 24 17:44:25 sigeon postgres[91789]: [5-30]->
Index Scan using "ind_users_modiifers_u+mod" on users_modifiers
(cost=0.00..4.15
Feb 24 17:44:25 sigeon postgres[91789]: [5-31]
Index Cond: ((users_modifiers.uid = public.logs.uid) AND
(users_modifiers.modifi
Feb 24 17:44:25 sigeon postgres[91789]: [5-32] ->
Index Scan using pkey_usersinfo on users_info (cost=0.00..4.20 rows=1
width=42)
Feb 24 17:44:25 sigeon postgres[91789]: [5-33]
Index Cond: (users_info.uid = users_modifiers.uid)
Feb 24 17:44:25 sigeon postgres[91789]: [5-34]
Filter: ((users_info.regdate >= $1) AND (users_info.regdate < $2))
Feb 24 17:44:25 sigeon postgres[91789]: [5-35] CONTEXT: PL/pgSQL function
"get_register_leveled_stats" line 3 at RETURN QUERY
Feb 24 17:44:25 sigeon postgres[91789]: [5-36] STATEMENT: SELECT * FROM
get_register_leveled_stats('02/24/11 00:00:00','02/25/11 00:00:00');
Feb 24 17:44:28 sigeon postgres[1166]: [5-1] LOG: server process (PID
91789) was terminated by signal 11: Segmentation fault
Feb 24 17:44:28 sigeon postgres[1166]: [6-1] LOG: terminating any other
active server processes
Feb 24 17:44:28 sigeon postgres[92550]: [7-1] FATAL: the database system is
in recovery mode
Feb 24 17:44:28 sigeon postgres[1166]: [7-1] LOG: archiver process (PID
1171) exited with exit code 1
Backtrace is:
(gdb) bt
#0 0x0060bf79 in quote_identifier ()
#1 0x004ed45c in explain_outNode ()
#2 0x004ee253 in ExplainPrintPlan ()
#3 0x00080120112a in explain_ExecutorEnd () from
/usr/local/pgsql/lib/auto_explain.so
#4 0x004fa3cf in PortalCleanup ()
#5 0x0067389a in PortalDrop ()
#6 0x005bf2e9 in exec_simple_query ()
#7 0x005bffd7 in PostgresMain ()
#8 0x00599287 in ServerLoop ()
#9 0x00599f7e in PostmasterMain ()
#10 0x0054ce64 in main ()
Since this is non-repeatable crash (this is common statistical query, run
tens times a day), i can't make a debug build of PG to show more info.
Executed query (get_register_leveled_stats) was following:
CREATE OR REPLACE FUNCTION get_register_leveled_stats(_from timestamp
without time zone, _to timestamp without time zone) RETURNS setof
f_grls_result AS
$BODY$
begin
return query
select z.*, z.a + z.b + z.c + z.d + z.e from (
select sum(other)::integer as a, sum(vk)::integer as b,
sum(vk_ref)::integer as c, sum(mailru)::integer as d, sum(od)::integer as e,
value::integer
from (
select uid,
case when eid is null and mlid is null
then 1 else 0 end as other,
case when eid is not null and net = 0
and referral is null then 1 else
0 end as vk,
case when eid is not null and net = 0
and referral is not null then 1
else 0 end as vk_ref,
case when eid is not null and net = 12
then 1 else 0 end as od,
case when mlid is not null then 1 else
0 end as mailru
from users_info
where regdate >= _from and regdate < _to
) z
inner join users_modifiers on (users_modifiers.uid =
z.uid)
where modifiyer = 808
and origin = 239
group by value
order by value asc
) z
;
end
$BODY$
LANGUAGE 'plpgsql' stable;
--
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 #5950: backend terminating after altering table
Tom Lane writes: > "alex" writes: > > 1. create table t ( > > ); > > 2. alter table t add childs t; > > 3. alter table t add id serial not null primary key; > > server closed the connection unexpectedly > > Hmm. This seems to be fixed in HEAD: Not fully. There are also two cases with Segmentation fault (from sql.ru forum): 1. create table t (); alter table t add childs t; create table selfchield_new (like t); 2. create table t (); alter table t add childs t; create table selfchield_new as select * from t; I have segmentation fault with current master 7c7fd882. -- Sergey Burladyan -- 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 #6407: Crash on queries to gin index with multiply values
ild/../src/backend/optimizer/plan/planner.c:1150 #15 0x7fe1efbaa761 in subquery_planner (glob=0x7fe1f1d84ae0, parse=0x7fe1f1d18160, parent_root=0x0, hasRecursion=0 '\000', tuple_fraction=0, subroot=0x7fff990fa2b8) at /home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/plan/planner.c:539 #16 0x7fe1efba9e80 in standard_planner (parse=0x7fe1f1d18160, cursorOptions=0, boundParams=0x0) at /home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/plan/planner.c:202 #17 0x7fe1efba9cd5 in planner (parse=0x7fe1f1d18160, cursorOptions=0, boundParams=0x0) at /home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/plan/planner.c:129 #18 0x7fe1efc2bd43 in pg_plan_query (querytree=0x7fe1f1d18160, cursorOptions=0, boundParams=0x0) at /home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/tcop/postgres.c:723 #19 0x7fe1efc2be03 in pg_plan_queries (querytrees=0x7fe1f1d84d80, cursorOptions=0, boundParams=0x0) at /home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/tcop/postgres.c:782 #20 0x7fe1efc2c122 in exec_simple_query (query_string=0x7fe1f1d170d0 "select * from tmp where f1 in (1, 2);") at /home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/tcop/postgres.c:947 #21 0x7fe1efc30991 in PostgresMain (argc=2, argv=0x7fe1f1c281f0, username=0x7fe1f1c28090 "seb") at /home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/tcop/postgres.c:3926 #22 0x7fe1efbe017d in BackendRun (port=0x7fe1f1c7d1e0) at /home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/postmaster/postmaster.c:3601 #23 0x7fe1efbdf75c in BackendStartup (port=0x7fe1f1c7d1e0) at /home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/postmaster/postmaster.c:3286 #24 0x7fe1efbdc679 in ServerLoop () at /home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/postmaster/postmaster.c:1455 #25 0x7fe1efbdbcff in PostmasterMain (argc=5, argv=0x7fe1f1c27180) at /home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/postmaster/postmaster.c:1116 #26 0x7fe1efb51899 in main (argc=5, argv=0x7fe1f1c27180) at /home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/main/main.c:199 /etc/postgresql/9.1/main/postgresql.conf data_directory = '/var/lib/postgresql/9.1/main' # use data in another directory hba_file = '/etc/postgresql/9.1/main/pg_hba.conf' # host-based authentication file ident_file = '/etc/postgresql/9.1/main/pg_ident.conf' # ident configuration file external_pid_file = '/var/run/postgresql/9.1-main.pid' # write an extra PID file port = 5432 # (change requires restart) max_connections = 100 # (change requires restart) unix_socket_directory = '/var/run/postgresql' # (change requires restart) ssl = true # (change requires restart) shared_buffers = 240MB # min 128kB temp_buffers = 180MB# min 800kB work_mem = 128MB# min 64kB maintenance_work_mem = 316MB# min 1MB synchronous_commit = off# synchronization level; on, off, or local effective_cache_size = 1528MB constraint_exclusion = on # on, off, or partition log_min_messages = notice # values in order of decreasing detail: log_connections = on log_disconnections = on log_line_prefix = '%t ' # special values: log_lock_waits = on # log lock waits >= deadlock_timeout log_temp_files = 0 # log temporary files equal or larger datestyle = 'iso, dmy' lc_messages = 'ru_RU.UTF-8' # locale for system error message lc_monetary = 'ru_RU.UTF-8' # locale for monetary formatting lc_numeric = 'ru_RU.UTF-8' # locale for number formatting lc_time = 'ru_RU.UTF-8' # locale for time formatting default_text_search_config = 'pg_catalog.russian' custom_variable_classes = 'custom,plperl,plperlu' # list of custom variable class names plperl.use_strict = true plperlu.use_strict = true -- Sergey Burladyan -- 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 #6407: Crash on queries to gin index with multiply values
Sergey Burladyan writes:
> #1 0x7fe1efbbc2b2 in get_leftop (clause=0x7fe1f1d85230) at
> /home/martin/debian/psql/9.1/build-area/postgresql-9.1-9.1.2/build/../src/backend/optimizer/util/clauses.c:189
I set breakpoint at src/backend/optimizer/util/clauses.c:188 and do some trace,
may be this can help:
Breakpoint 1, get_leftop (clause=0x7fe1f1d5af30)
(gdb) print *expr
$1 = {xpr = {type = T_OpExpr}, opno = 96, opfuncid = 65, opresulttype = 16,
opretset = 0 '\000', opcollid = 0,
inputcollid = 0, args = 0x7fe1f1d5cb98, location = 0}
Breakpoint 1, get_leftop (clause=0x7fe1f1d5c4b0)
(gdb) print *expr
$2 = {xpr = {type = T_OpExpr}, opno = 96, opfuncid = 65, opresulttype = 16,
opretset = 0 '\000', opcollid = 0,
inputcollid = 0, args = 0x7fe1f1d5cc40, location = 0}
Breakpoint 1, get_leftop (clause=0x7fe1f1d5c0b8)
(gdb) print *expr
$3 = {xpr = {type = T_ScalarArrayOpExpr}, opno = 96, opfuncid = 65,
opresulttype = 1, opretset = 0 '\000', opcollid = 0,
inputcollid = 4057317752, args = 0x1b, location = -237649736}
--
Sergey Burladyan
--
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 #6480: NLS text width problem
eshkin...@gmail.com writes: > The following bug has been logged on the website: > > Bug reference: 6480 > Logged by: Sergey Burladyan > Email address: eshkin...@gmail.com > PostgreSQL version: 9.1.2 > Operating system: Debian testing > Description: > > This code incorrectly calculate width for translated text if it multibyte > string. strlen(ct) vs. UTF-8 > > src/bin/psql/describe.c:2100 Test case: create table t (); create table t_1 () inherits (t); create table t_2 () inherits (t); create table d () inherits (t_1, t_2); \d+ t \d+ d Table "public.t" Column | Type | Modifiers | Storage | Description +--+---+-+- Child tables: t_1, t_2 Has OIDs: no Table "public.d" Column | Type | Modifiers | Storage | Description +--+---+-+- Inherits: t_1, t_2 Has OIDs: no English, correct indentation: . . . Child tables: t_1, t_2 . . . Inherits: t_1, t_2 Russian (UTF-8), wrong indentation: Таблица "public.t" Колонка | Тип | Модификаторы | Хранилище | Описание -+-+--+---+-- Дочерние таблицы: t_1, t_2 Содержит OID: нет Таблица "public.d" Колонка | Тип | Модификаторы | Хранилище | Описание -+-+--+---+-- Наследует: t_1, t_2 Содержит OID: нет -- Sergey Burladyan -- 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 #6480: NLS text width problem
Peter Eisentraut writes:
> On ons, 2012-02-22 at 22:37 +0400, Sergey Burladyan wrote:
> > eshkin...@gmail.com writes:
> >
> > > The following bug has been logged on the website:
> > >
> > > Bug reference: 6480
> > > Logged by: Sergey Burladyan
> > > Email address: eshkin...@gmail.com
> > > PostgreSQL version: 9.1.2
> > > Operating system: Debian testing
> > > Description:
> > >
> > > This code incorrectly calculate width for translated text if it multibyte
> > > string. strlen(ct) vs. UTF-8
> > >
> > > src/bin/psql/describe.c:2100
>
> Can you prepare a patch?
>
Surely, I was sent this patch to pgsql-hackers and added to the commitfest-next
to
be sure I'll never lost it
https://commitfest.postgresql.org/action/patch_view?id=816
Unfortunately, I was sent it with content-disposition: inline by mistake, as
result, web interface divided it by two independent parts. Also this patch for
9.1
To resolve this issue, I was rebased this patch to current master (bc97c38) and
send
it as attachment. Here it is:
>From 489ce7f9e8ccea9d760504d3b100b67d11968516 Mon Sep 17 00:00:00 2001
From: Sergey Burladyan
Date: Tue, 28 Feb 2012 04:41:15 +0400
Subject: [PATCH] Fix NLS text width and pg_wcswidth function
---
src/bin/psql/describe.c |4 ++--
src/bin/psql/mbprint.c |7 ---
src/bin/psql/mbprint.h |2 +-
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index 4eee4be..de89b09 100644
*** a/src/bin/psql/describe.c
--- b/src/bin/psql/describe.c
*** describeOneTableDetails(const char *sche
*** 2165,2171
if (i == 0)
printfPQExpBuffer(&buf, "%s: %s", s, PQgetvalue(result, i, 0));
else
! printfPQExpBuffer(&buf, "%*s %s", (int) strlen(s), "", PQgetvalue(result, i, 0));
if (i < tuples - 1)
appendPQExpBuffer(&buf, ",");
--- 2165,2171
if (i == 0)
printfPQExpBuffer(&buf, "%s: %s", s, PQgetvalue(result, i, 0));
else
! printfPQExpBuffer(&buf, "%*s %s", pg_wcswidth(s, strlen(s), pset.encoding), "", PQgetvalue(result, i, 0));
if (i < tuples - 1)
appendPQExpBuffer(&buf, ",");
*** describeOneTableDetails(const char *sche
*** 2206,2212
ct, PQgetvalue(result, i, 0));
else
printfPQExpBuffer(&buf, "%*s %s",
! (int) strlen(ct), "",
PQgetvalue(result, i, 0));
if (i < tuples - 1)
appendPQExpBuffer(&buf, ",");
--- 2206,2212
ct, PQgetvalue(result, i, 0));
else
printfPQExpBuffer(&buf, "%*s %s",
! pg_wcswidth(ct, strlen(ct), pset.encoding), "",
PQgetvalue(result, i, 0));
if (i < tuples - 1)
appendPQExpBuffer(&buf, ",");
diff --git a/src/bin/psql/mbprint.c b/src/bin/psql/mbprint.c
index 32fc756..f246d00 100644
*** a/src/bin/psql/mbprint.c
--- b/src/bin/psql/mbprint.c
*** mb_utf_validate(unsigned char *pwcs)
*** 172,178
* only appear on one line. OTOH it is easier to use if this applies to you.
*/
int
! pg_wcswidth(const unsigned char *pwcs, size_t len, int encoding)
{
int width = 0;
--- 172,178
* only appear on one line. OTOH it is easier to use if this applies to you.
*/
int
! pg_wcswidth(const char *pwcs, size_t len, int encoding)
{
int width = 0;
*** pg_wcswidth(const unsigned char *pwcs, s
*** 181,195
int chlen,
chwidth;
! chlen = PQmblen((const char *) pwcs, encoding);
if (chlen > len)
break;/* Invalid string */
! chwidth = PQdsplen((const char *) pwcs, encoding);
if (chwidth > 0)
width += chwidth;
pwcs += chlen;
}
return width;
}
--- 181,196
int chlen,
chwidth;
! chlen = PQmblen(pwcs, encoding);
if (chlen > len)
break;/* Invalid string */
! chwidth = PQdsplen(pwcs, encoding);
if (chwidth > 0)
width += chwidth;
pwcs += chlen;
+ len -= chlen;
}
return width;
}
diff --git a/src/bin/psql/mbprint.h b/src/bin/psql/mbprint.h
index 83050ff..01064d3 100644
*** a/src/bin/psql/mbprint.h
--- b/src/bin/psql/mbprint.h
*** struct lineptr
*** 10,16
};
extern unsigned char *mbvalidate(unsigned char *pwcs, int encoding);
! extern int pg_wcswidth(const unsigned char *pwcs, size_t len, int encoding);
extern void pg_wcsformat(const unsigned char *pwcs, size_t len, int encoding, struct lineptr * lines, int count);
extern void pg_wcssize(const unsigned char *pwcs, size_t len, int encoding,
int *width, int *height, int *format_s
Re: [BUGS] BUG #6480: NLS text width problem
Tom Lane writes: > I think it'd be better to avoid depending on %*s for the data string > and instead use it (with appropriate adjustment of the calculation) > for the space-separator part of the format. Since that's a constant > empty string, there shouldn't be any possibility of libc doing something > other than what we intend. Sorry, I'm going on vacation for four days. Can't answer right now... -- Sergey Burladyan -- 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 #6480: NLS text width problem
Tom Lane writes: > Ah, nevermind --- I re-read the patch and realized that it was already > doing exactly what I said. Committed, sorry for the noise. Great, thank you, Tom! -- Sergey Burladyan -- 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 #6690: ALL and ANY array operators
The following bug has been logged on the website: Bug reference: 6690 Logged by: sergey Email address: sergey-1...@yandex.ru PostgreSQL version: 9.1.2 Operating system: FreeBSD 8.1 Description: As I see in documentation, http://www.postgresql.org/docs/current/static/functions-aggregate.html there is an ambiguity with bool_or aggregate and ANY array operator, so bool_or cannot has standard name ANY. So ANY should always mean array operator. But such query produces syntax error: select 1 = ANY((select ARRAY[1, 2]::integer[])) I.e. when I try to check is some element in array, that is calculated in subquery, I cannot. I can use: select ARRAY[1] && (select ARRAY[1, 2]::integer[]) but what about ANY operator? For example this works: select 1 = ANY(ARRAY[1, 2]::integer[]); select 1 in (select * from unnest(ARRAY[1, 2]::integer[])) -- 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 #7710: Xid epoch is not updated properly during checkpoint
Hi all. We also have reproduced this behaviour of txid wraparound. pg version 9.0.5. We have done some test. We are using hot standby and our chekpoint interval is closly to one hour (actually, our pg does chekpoints all time). So probability of intersection active chekpoint and getting max txid is near 100% First time we got fail whith this wraparound was some month ago during londiste-replication. and we haven't found any satisfactory explaination, but now, we get new conditions. Please, review checkpoint and hotstandy. Does anybody know this bug exists in head? We have done our test in 9.2.1 and bug have been found again: --- checkpoint begin $ /usr/lib/postgresql/9.2/bin/psql -p 5430 -h `pwd`/s -d postgres -c 'select now(),txid_current(),txid_current()-2^32' now | txid_current | ?column? --+--+-- 2012-11-30 19:48:48.57472+04 | 4294967730 | 434 (1 row) $ /usr/lib/postgresql/9.2/bin/psql -p 5430 -h `pwd`/s -d postgres -c 'select now(),txid_current(),txid_current()-2^32' now | txid_current | ?column? ---+--+-- 2012-11-30 19:49:11.758169+04 | 4294967731 | 435 (1 row) --- checkpoint end $ /usr/lib/postgresql/9.2/bin/psql -p 5430 -h `pwd`/s -d postgres -c 'select now(),txid_current(),txid_current()-2^32' now | txid_current | ?column? ---+--+- 2012-11-30 19:51:06.302396+04 | 439 | -4294966857 (1 row) Note this previous threads: Standbys, txid_current_snapshot, wraparound http://archives.postgresql.org/pgsql-hackers/2012-06/msg00888.php -- Sergey Burladyan -- 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 #7916: memory leak with array_agg
Tom Lane writes: > AFAICT there's no actual leak here; array_agg is just optimized for > speed rather than space. It eats about 8K per hashtable entry. > While the planner knows that, it's got no good idea how many groups > will be produced by the query, so it underestimates the space needed > --- and the HashAggregate code is not currently capable of spilling > the hashtable to disk, so the table balloons well past the intended > work_mem limit. Aha, I found this "8K per hashtable entry" with ltrace and now understand what is going on here: === array_agg malloc calls count === === myagg malloc calls count=== 3 malloc(1024)3 malloc(1024) 3 malloc(1048576) 3 malloc(1048576) 3 malloc(131072) 3 malloc(131072) 1 malloc(16056) 4 malloc(16384) 5 malloc(16384) 2 malloc(16440) 2 malloc(16440) 1 malloc(2048) 1 malloc(2048)3 malloc(2097152) 3 malloc(2097152) 3 malloc(262144) 3 malloc(262144) 3 malloc(32768) 3 malloc(32768) 1 malloc(32824) 1 malloc(32824) 1 malloc(4096) 1 malloc(4096)3 malloc(4194304) 3 malloc(4194304) 3 malloc(524288) 3 malloc(524288) 3 malloc(65536) 3 malloc(65536) 12 malloc(8192) 724151 malloc(8192)1 malloc(8296) 1 malloc(8296) 29 malloc(8360) 44 malloc(8360) 16 malloc(8388608) 8 malloc(8388608) Thank you for answer Tom! > Although no real fix for this is within easy reach, it strikes me > that we could possibly ameliorate things a bit by tweaking the > memory context size parameters used by accumArrayResult(). > It would likely be reasonable to set the min size to 1K or so not 8K. > This would make things a trifle slower when the actual space requirement > exceeds 1K, but probably not by enough to notice. Looks good. > BTW, I don't believe your assertion that the handmade aggregate does > this in 7MB. Even a very optimistic calculation puts the space needed > for 70 10-element integer arrays at forty-some MB, and when I try > it I see more like 100MB consumed thanks to hashtable overhead. Yes you are right, Tom. My mistake. -- Sergey Burladyan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Completely broken replica after PANIC: WAL contains references to invalid pages
80557557 280557558 280557559 280557560 280557561 280557562 280557563 280557564 280557565 280557566 280557567 280557568 280557569 280557570 280557571 280557572 280557573 280557574 280557575 280557576 280557577 280557578 280557579 280557580 280557581 280557582 280557583 2013-03-27 10:43:03 MSK 1532 @ from [vxid: txid:0] [] LOG: startup process (PID 1535) exited with exit code 1 2013-03-27 10:43:03 MSK 1532 @ from [vxid: txid:0] [] LOG: terminating any other active server processes Thank you in advance. -- Kind regards, Sergey Konoplev Database and Software Consultant Profile: http://www.linkedin.com/in/grayhemp Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979 Skype: gray-hemp Jabber: gray...@gmail.com -- 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] Completely broken replica after PANIC: WAL contains references to invalid pages
280483356 280483368 280483377 280483382 280483392 >>280483404 280483416 280483429 280483440 280483451 280483460 280483472 >>280483487 280483500 280483516 280483530 280483541 280483555 280483565 >>280483574 280483585 280483595 280483604 280483607 280483617 280483626 >>280483636 280483646 280483656 280483665 280483677 280483688 280483699 >>280483709 280483719 280483730 280483739 280483749 280483759 280483761 >>280483771 280483782 280483799 280483800 280483811 280483821 280483824 >>280483836 280483847 280483859 280483871 280483874 280483883 280483897 >>280483906 280483915 280483925 280483937 280483948 280483958 >>2013-03-27 10:43:02 MSK 1535 @ from [vxid:1/0 txid:0] [] LOG: file >>"pg_subtrans/10B7" doesn't exist, reading as zeroes >>2013-03-27 10:43:02 MSK 1535 @ from [vxid:1/0 txid:0] [] CONTEXT: >>xlog redo xid assignment xtop 280482270: subxacts: 280485056 280485070 >>280485083 280485086 280485098 280485113 280485132 280485144 280485156 >>280485167 280485178 280485188 280485201 280485217 280485234 280485249 >>280485267 280485293 280485309 280485327 280485333 280485345 280485353 >>280485373 280485388 280485405 280485420 280485434 280485457 280485476 >>280485482 280485507 280485516 280485531 280485537 280485550 280485565 >>280485568 280485585 280485587 280485601 280485613 280485634 280485639 >>280485656 280485669 280485684 280485690 280485693 280485712 280485730 >>280485754 280485757 280485779 280485801 280485808 280485811 280485830 >>280485856 280485880 280485900 280485920 280485941 280485946 >> >>[ skipped several more messages of this kind] >> >>2013-03-27 10:43:03 MSK 1535 @ from [vxid:1/0 txid:0] [] LOG: file >>"pg_subtrans/10B8" doesn't exist, reading as zeroes >>2013-03-27 10:43:03 MSK 1535 @ from [vxid:1/0 txid:0] [] CONTEXT: >>xlog redo xid assignment xtop 280549936: subxacts: 28014 28015 >>28016 28017 28018 28019 28020 28021 28022 >>28023 28024 28025 28026 28027 28028 28029 >>28030 28031 28032 28033 28034 28035 28036 >>28037 28038 28039 28040 28041 28042 28043 >>28044 28045 28046 28047 28048 28049 28050 >>28051 28052 28053 28054 28055 28056 28057 >>28058 28059 28060 28061 28062 28063 28064 >>28065 28066 28067 28068 28069 28070 28071 >>28072 28073 28074 28075 28076 28077 >>2013-03-27 10:43:03 MSK 1535 @ from [vxid:1/0 txid:0] [] FATAL: >>could not access status of transaction 280557568 >>2013-03-27 10:43:03 MSK 1535 @ from [vxid:1/0 txid:0] [] DETAIL: >>Could not read from file "pg_subtrans/10B8" at offset 253952: Success. >>2013-03-27 10:43:03 MSK 1535 @ from [vxid:1/0 txid:0] [] CONTEXT: >>xlog redo xid assignment xtop 280555981: subxacts: 280557520 280557521 >>280557522 280557523 280557524 280557525 280557526 280557527 280557528 >>280557529 280557530 280557531 280557532 280557533 280557534 280557535 >>280557536 280557537 280557538 280557539 280557540 280557541 280557542 >>280557543 280557544 280557545 280557546 280557547 280557548 280557549 >>280557550 280557551 280557552 280557553 280557554 280557555 280557556 >>280557557 280557558 280557559 280557560 280557561 280557562 280557563 >>280557564 280557565 280557566 280557567 280557568 280557569 280557570 >>280557571 280557572 280557573 280557574 280557575 280557576 280557577 >>280557578 280557579 280557580 280557581 280557582 280557583 >>2013-03-27 10:43:03 MSK 1532 @ from [vxid: txid:0] [] LOG: startup >>process (PID 1535) exited with exit code 1 >>2013-03-27 10:43:03 MSK 1532 @ from [vxid: txid:0] [] LOG: >>terminating any other active server processes >> >>Thank you in advance. >> >>-- >>Kind regards, >>Sergey Konoplev >>Database and Software Consultant >> >>Profile: http://www.linkedin.com/in/grayhemp >>Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) >>888-1979 >>Skype: gray-hemp >>Jabber: gray...@gmail.com > > > --- > Please excuse brevity and formatting - I am writing this on my mobile phone. > --- > Please excuse brevity and formatting - I am writing this on my mobile phone. -- Kind regards, Sergey Konoplev Database and Software Consultant Profile: http://www.linkedin.com/in/grayhemp Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979 Skype: gray-hemp Jabber: gray...@gmail.com -- 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] Completely broken replica after PANIC: WAL contains references to invalid pages
On Fri, Mar 29, 2013 at 2:38 PM, Andres Freund wrote: > I have to admit, I find it a bit confusing that so many people report a > bug and then immediately destroy all evidence of the bug. Just seems to > a happen a bit too frequently. You see, businesses usually need it up ASAP again. Sorry, I must have note down the output of pg_controldata straight after it got broken, I just have not came up to it. > Thats not a pg_controldata output from the broken replica though, or is > it? I guess its from a new standby? That was the output from the standby that was rsync-ed on top of the broken one. I thought you might find something useful in it. Can I test your guess some other way? And what was the guess? -- Kind regards, Sergey Konoplev Database and Software Consultant Profile: http://www.linkedin.com/in/grayhemp Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979 Skype: gray-hemp Jabber: gray...@gmail.com -- 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] Completely broken replica after PANIC: WAL contains references to invalid pages
On Tue, Apr 2, 2013 at 11:26 AM, Andres Freund wrote: > The attached patch fixes this although I don't like the way it knowledge of > the > point up to which StartupSUBTRANS zeroes pages is handled. Thank you for the patch, Andres. Is it included in 9.2.4? BTW, it has happened again and I am going to make a copy of the cluster to be able to provide you some extra information. Do you still need it? -- Kind regards, Sergey Konoplev Database and Software Consultant Profile: http://www.linkedin.com/in/grayhemp Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979 Skype: gray-hemp Jabber: gray...@gmail.com -- 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] Completely broken replica after PANIC: WAL contains references to invalid pages
On Fri, Apr 5, 2013 at 7:15 AM, Andres Freund wrote: > Cool. It would be very helpful if you could apply the patch and verify > that it works, it has been written somewhat blindly. Also I am afraid > that at least last time there was a second bug involved. Okay, I will try to talk to admins but I am afraid it could take long. > Could you show the log? 2013-04-05 17:26:31 MSK 2113 @ from [vxid: txid:0] [] LOG: database system was shut down in recovery at 2013-04-05 17:18:02 MSK 2013-04-05 17:26:32 MSK 2113 @ from [vxid: txid:0] [] LOG: entering standby mode 2013-04-05 17:26:32 MSK 2113 @ from [vxid:1/0 txid:0] [] LOG: redo starts at 25BD/907338F8 2013-04-05 17:26:32 MSK 2113 @ from [vxid:1/0 txid:0] [] LOG: file "pg_subtrans/28E5" doesn't exist, reading as zeroes 2013-04-05 17:26:32 MSK 2113 @ from [vxid:1/0 txid:0] [] CONTEXT: xlog redo xid assignment xtop 686136255: subxacts: 686137344 686137345 686137346 686137347 686137348 686137349 686137350 686137351 686137352 686137353 686137354 686137355 686137356 686137357 686137358 686137359 686137360 686137361 686137362 686137363 686137364 686137365 686137366 686137367 686137368 686137369 686137370 686137371 686137372 686137373 686137374 686137375 686137376 686137377 686137378 686137379 686137380 686137381 686137382 686137383 686137384 686137385 686137386 686137387 686137388 686137389 686137390 686137391 686137392 686137393 686137394 686137395 686137396 686137397 686137398 686137399 686137400 686137401 686137402 686137403 686137404 686137405 686137406 686137407 2013-04-05 17:26:32 MSK 2113 @ from [vxid:1/0 txid:0] [] LOG: file "pg_subtrans/28E5" doesn't exist, reading as zeroes 2013-04-05 17:26:32 MSK 2113 @ from [vxid:1/0 txid:0] [] CONTEXT: xlog redo xid assignment xtop 686136255: subxacts: 686139330 686139331 686139332 686139333 686139334 686139335 686139336 686139337 686139338 686139339 686139340 686139341 686139342 686139343 686139344 686139345 686139346 686139347 686139348 686139349 686139350 686139351 686139352 686139353 686139354 686139355 686139356 686139357 686139358 686139359 686139360 686139361 686139362 686139363 686139364 686139365 686139366 686139367 686139368 686139369 686139370 686139371 686139372 686139373 686139374 686139375 686139376 686139377 686139378 686139379 686139380 686139381 686139382 686139383 686139384 686139385 686139386 686139387 686139388 686139389 686139390 686139391 686139392 686139393 [some more like this] 2013-04-05 17:26:36 MSK 2113 @ from [vxid:1/0 txid:0] [] LOG: file "pg_subtrans/28E6" doesn't exist, reading as zeroes 2013-04-05 17:26:36 MSK 2113 @ from [vxid:1/0 txid:0] [] CONTEXT: xlog redo xid assignment xtop 686216055: subxacts: 686222447 686222448 686222449 686222450 686222451 686222452 686222453 686222454 686222455 686222456 686222457 686222459 686222460 686222461 686222462 686222463 686222464 686222502 686222561 686222647 686222722 686223272 686223359 686223360 686223361 686223363 686223364 686223365 686223366 686223367 686223368 686223369 686223370 686223371 686223372 686223373 686223374 686223375 686223376 686223377 686223378 686223379 686223380 686223381 686223382 686223383 686223384 686223385 686223386 686223387 686223388 686223389 686223390 686223391 686223392 686223393 686223394 686223395 686223396 686223397 686223398 686223399 686223400 686223401 2013-04-05 17:26:36 MSK 2113 @ from [vxid:1/0 txid:0] [] FATAL: could not access status of transaction 686225586 2013-04-05 17:26:36 MSK 2113 @ from [vxid:1/0 txid:0] [] DETAIL: Could not read from file "pg_subtrans/28E6" at offset 253952: Success. 2013-04-05 17:26:36 MSK 2113 @ from [vxid:1/0 txid:0] [] CONTEXT: xlog redo xid assignment xtop 686225585: subxacts: 686225586 686225587 686225588 686225589 686225590 686225591 686225592 686225593 686225594 686225595 686225596 686225597 686225598 686225599 686225600 686225601 686225602 686225603 686225604 686225605 686225606 686225607 686225608 686225609 686225610 686225611 686225612 686225613 686225614 686225615 686225616 686225617 686225621 686225622 686225625 686225626 686225628 686225632 686225633 686225636 686225637 686225638 686225639 686225640 686225641 686225644 686225645 686225646 686225649 686225650 686225657 686225658 686225661 686225662 686225665 686225666 686225670 686225671 686225672 686225673 686225678 686225679 686225684 686225685 2013-04-05 17:26:36 MSK 2110 @ from [vxid: txid:0] [] LOG: startup process (PID 2113) exited with exit code 1 2013-04-05 17:26:36 MSK 2110 @ from [vxid: txid:0] [] LOG: terminating any other active server processes -- Kind regards, Sergey Konoplev Database and Software Consultant Profile: http://www.linkedin.com/in/grayhemp Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979 Skype: gray-hemp Jabber: gray...@gmail.com -- 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] Completely broken replica after PANIC: WAL contains references to invalid pages
On Fri, Apr 5, 2013 at 7:33 AM, Andres Freund wrote: > Looks like it could be fixed by the patch. But that seems to imply that > you restarted not long before that? Could you check if theres a > different error before those? Yes it had happened straight after restart this time. There are no any errors in logs before it. -- Kind regards, Sergey Konoplev Database and Software Consultant Profile: http://www.linkedin.com/in/grayhemp Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979 Skype: gray-hemp Jabber: gray...@gmail.com -- 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] Completely broken replica after PANIC: WAL contains references to invalid pages
On Tue, Apr 2, 2013 at 11:26 AM, Andres Freund wrote: > The attached patch fixes this although I don't like the way it knowledge of > the > point up to which StartupSUBTRANS zeroes pages is handled. One month has passed since the patched version was installed in our production environment and can confirm that everything works perfect. Thank you very much for your prompt help, Andres. -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA Profile: http://www.linkedin.com/in/grayhemp Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979 Skype: gray-hemp Jabber: gray...@gmail.com -- 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] Completely broken replica after PANIC: WAL contains references to invalid pages
Hi, On Thu, May 9, 2013 at 7:28 PM, Sergey Konoplev wrote: > On Tue, Apr 2, 2013 at 11:26 AM, Andres Freund wrote: >> The attached patch fixes this although I don't like the way it knowledge of >> the >> point up to which StartupSUBTRANS zeroes pages is handled. > > One month has passed since the patched version was installed in our > production environment and can confirm that everything works perfect. > Thank you very much for your prompt help, Andres. Are there any plans to commit this patch and what version it is going to be done to? Thank you. -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA Profile: http://www.linkedin.com/in/grayhemp Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979 Skype: gray-hemp Jabber: gray...@gmail.com -- 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] Completely broken replica after PANIC: WAL contains references to invalid pages
On Mon, Jun 10, 2013 at 11:43 PM, Simon Riggs wrote: > On 11 June 2013 04:36, Sergey Konoplev wrote: >> Are there any plans to commit this patch and what version it is going >> to be done to? > > I'll be committing this soon, since we're likely coming up to the next > point release soon. I see, thank you. Just curious, what is the planned date for the next minor release, and BTW where is it possible to see the roadmap for minor releases? > Thanks for the reminder. You are welcome. -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA Profile: http://www.linkedin.com/in/grayhemp Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979 Skype: gray-hemp Jabber: gray...@gmail.com -- 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] Completely broken replica after PANIC: WAL contains references to invalid pages
Hi all, I recently noticed that I continue to receive "allocation failure" messages from postmaster in /var/log/messages on the server where the problem occurred. Aug 17 23:00:51 tms2 kernel: : postmaster: page allocation failure. order:5, mode:0xd0 Aug 17 23:00:51 tms2 kernel: : Pid: 21223, comm: postmaster Not tainted 2.6.32-279.22.1.el6.x86_64 #1 Aug 17 23:00:51 tms2 kernel: : Call Trace: Aug 17 23:00:51 tms2 kernel: : [] ? __alloc_pages_nodemask+0x77f/0x940 Aug 17 23:00:51 tms2 kernel: : [] ? kmem_getpages+0x62/0x170 Aug 17 23:00:51 tms2 kernel: : [] ? fallback_alloc+0x1ba/0x270 Aug 17 23:00:51 tms2 kernel: : [] ? cache_grow+0x2cf/0x320 Aug 17 23:00:51 tms2 kernel: : [] ? cache_alloc_node+0x99/0x160 Aug 17 23:00:51 tms2 kernel: : [] ? dma_pin_iovec_pages+0xb5/0x230 Aug 17 23:00:51 tms2 kernel: : [] ? __kmalloc+0x189/0x220 Aug 17 23:00:51 tms2 kernel: : [] ? dma_pin_iovec_pages+0xb5/0x230 Aug 17 23:00:51 tms2 kernel: : [] ? lock_sock_nested+0xac/0xc0 Aug 17 23:00:51 tms2 kernel: : [] ? tcp_recvmsg+0x4ca/0xe80 Aug 17 23:00:51 tms2 kernel: : [] ? inet_recvmsg+0x5a/0x90 Aug 17 23:00:51 tms2 kernel: : [] ? sock_recvmsg+0x133/0x160 Aug 17 23:00:51 tms2 kernel: : [] ? autoremove_wake_function+0x0/0x40 Aug 17 23:00:51 tms2 kernel: : [] ? do_sync_read+0xfa/0x140 Aug 17 23:00:51 tms2 kernel: : [] ? sys_recvfrom+0xee/0x180 Aug 17 23:00:51 tms2 kernel: : [] ? poll_select_set_timeout+0x8d/0xa0 Aug 17 23:00:51 tms2 kernel: : [] ? audit_syscall_entry+0x1d7/0x200 Aug 17 23:00:51 tms2 kernel: : [] ? system_call_fastpath+0x16/0x1b Except these messages everything is just fine. The server is a passive (very rarely queried) hot standby. Are there any ideas of why and what could it be? Thank you. On Tue, Jun 11, 2013 at 6:50 AM, Tom Lane wrote: > Sergey Konoplev writes: >> Just curious, what is the planned date for the next minor release, and >> BTW where is it possible to see the roadmap for minor releases? > > There is no planned date, and certainly no "roadmap". We make minor > releases when the core team judges that enough (or severe enough) > fixes have accumulated since the last time. Historically we've averaged > about four minor releases a year, but that's not set in stone anywhere. > > regards, tom lane -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA http://www.linkedin.com/in/grayhemp +1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979 gray...@gmail.com -- 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] Completely broken replica after PANIC: WAL contains references to invalid pages
On Tue, Jun 11, 2013 at 6:50 AM, Tom Lane wrote: > Sergey Konoplev writes: >> Just curious, what is the planned date for the next minor release, and >> BTW where is it possible to see the roadmap for minor releases? > > There is no planned date, and certainly no "roadmap". We make minor > releases when the core team judges that enough (or severe enough) > fixes have accumulated since the last time. Historically we've averaged > about four minor releases a year, but that's not set in stone anywhere. Could you please give me a hint of how to check if this patch was included in 9.2.5 or not? -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA http://www.linkedin.com/in/grayhemp +1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979 gray...@gmail.com -- 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] Completely broken replica after PANIC: WAL contains references to invalid pages
On Thu, Oct 10, 2013 at 2:48 PM, Alvaro Herrera wrote: >> Could you please give me a hint of how to check if this patch was >> included in 9.2.5 or not? > > Yes, this was committed in June: > > commit 99ee15b315c187045a95db7b27fd9d866aea93e0 > Author: Simon Riggs > Date: Sun Jun 23 11:05:02 2013 +0100 Good news, thank you. -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA http://www.linkedin.com/in/grayhemp +1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979 gray...@gmail.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Postresql & triggers
Hi all!
Can anybody help me with it?
Used FreeBSD 3.3-STABLE, PostgreSQL7.0beta2( and 6.5.è )
compiled with options: --enable-locale --enable-recode
--enable-multibyte=KOI8 --with-odbc --with-CC=gcc --with-CXX=gcc
--with-perl --with-tcl --with-maxbackends=5 --with-include=/usr/local/include
--with-tclconfig=/usr/local/lib/tcl8.0 --with-tkconfig=/usr/local/lib/tk8.0
sklad=> create table aaa ( id int4, hmm int4 );
CREATE
sklad=> \d aaa
Table "aaa"
Attribute | Type | Modifier
---+-+--
id| integer |
hmm | integer |
sklad=> create table bbb ( id int4, hmm2 int4 );
CREATE
sklad=> \d bbb
Table "bbb"
Attribute | Type | Modifier
---+-+--
id| integer |
hmm2 | integer |
sklad=> create function proc_del_aaa ( int4 ) returns opaque as ' begin
delete from bbb where id = $1; end; ' language 'plpgsql';
CREATE
sklad=> create trigger trig_del_aaa after delete on aaa FOR EACH ROW
EXECUTE PROCEDURE proc_del_aaa ( id );
ERROR: CreateTrigger: function proc_del_aaa() does not exist
sklad=> create trigger trig_del_aaa after delete on aaa FOR EACH ROW
EXECUTE PROCEDURE proc_del_aaa ( 'id' );
ERROR: CreateTrigger: function proc_del_aaa() does not exist
sklad=> drop function proc_del_aaa( int4 );
DROP
sklad=>
--+---+
... One child is not enough, but two are far too many.|FreeBSD|
| The power to serve! |
Mikheev Sergey <[EMAIL PROTECTED]> |http://www.FreeBSD.org/|
+===+
[BUGS] Continue: Bug #924: Segmentation fault in libpq/PQconsumeInput onSSL connection
I try to explain this bug. Attached files contains example and patch
for libpq.
I hope, that you look at it and replay me what you think.
---
Segey N. Yatskevich <[EMAIL PROTECTED]>
#
# $Id$
#
ssl-async-query: ssl-async-query.cc
c++ -g -I`pg_config --includedir` /usr/lib/libpq.so.3 -o ssl-async-query
ssl-async-query.cc
clean:
rm -f ssl-async-query
--- fe-secure.c.orig2003-01-09 02:18:35 +0300
+++ fe-secure.c 2003-04-02 02:06:27 +0400
@@ -268,7 +268,10 @@
case SSL_ERROR_NONE:
break;
case SSL_ERROR_WANT_READ:
- n = pqsecure_read(conn, ptr, len);
+ // I think this mean, that SSL layer have
+ // no any data for us and we must try
+ // to read it later.
+ n = 0;
break;
case SSL_ERROR_SYSCALL:
printfPQExpBuffer(&conn->errorMessage,
@@ -314,7 +317,10 @@
case SSL_ERROR_NONE:
break;
case SSL_ERROR_WANT_WRITE:
- n = pqsecure_write(conn, ptr, len);
+ // I think this mean, that SSL layer have
+ // no free space for buffering our data and
+ // we must try to write it later.
+ n = 0;
break;
case SSL_ERROR_SYSCALL:
printfPQExpBuffer(&conn->errorMessage,
/*
* SSL-test
*/
#include
#include
static void
exit_nicely (PGconn *conn) {
std::cerr << "ERROR: " << PQerrorMessage (conn) << '\n';
PQfinish (conn);
exit (1);
}
int
main (int _argc, char *_argv[]) {
PGconn *conn = PQconnectdb ("user=postgres dbname=template1 host=127.0.0.1
requiressl=1");
if (PQstatus (conn) == CONNECTION_BAD)
exit_nicely (conn);
PQsendQuery (conn, "select * from pg_class; select * from pg_type; select *
from pg_proc");
for (;;) {
std::cout << "before DANGEROUS section of code\n";
#ifndef NO_STACK_OVERFLOW_DEMO
// This is a DANGEROUS code. If we call PQconsumeInput here,
// after getting last PGresult, we will go into infinite
// recursive call of pqsecure_read on SSL_ERROR_WANT_READ.
PQconsumeInput (conn);
if (PQisBusy (conn))
continue;
// Call PQcounsumeInput on SSL connection when server
// don't send any data to us is DANGEROUS.
#else
// This code is safe, becouse end of data determine before
// call of PQconsumeInput and we don't go into pqsecure_read
// when server have no data.
if (PQisBusy (conn)) {
PQconsumeInput (conn);
continue;
}
#endif
// But I think PQconsumeInput must be safe to be called in
// any time, becouse, for example, we can use it not only
// for async query processing, but for getting asynhronous
// notification from server in case when we don't send any
// query to it and can't be sure, that server have data for
// us.
std::cout << "after DANGEROUS section of code\n";
// When we don't use SSL this code in both case is completly
// safe, becouse recv simple return 0 if no data avaliable.
// I think this is good for SSL connection too.
PGresult *res = PQgetResult (conn);
if (res) {
if (PQresultStatus (res) == PGRES_TUPLES_OK)
std::cout << "SELECT\n";
else
std::cerr << "UNKNOWN\n";
PQclear (res);
continue;
}
break;
}
PQfinish(conn);
return 0;
}
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[BUGS] Bug in byteaout code in all PostgreSQL versions
Hello!
bytea-test.cxx -- contains detailed description of the bug and test
plan and code.
varlena.c.diff -- patch for PostgreSQL 7.5devel
src/backend/utils/adt/varlena.c#byteaout
fe-exec.c.diff -- patch (optional) for PostgreSQL 7.5devel
src/interface/libpq/fe-exec.c#PQescapeBytea
test.data -- contains test data :-))
--
Sergey N. Yatskevich <[EMAIL PROTECTED]>
GosNIIAS
/**
* @file
* @brief This test show bug in byteaout PostgreSQL code
* @author Sergey N. Yatskevich
*
* If we have a different client and server encodings and client and server locales are
* not C(ASCII) then path of bytea string for client->server transfer is:
* -# encode binary data on client with PQescapeBytea (encode in \\ooo form all
symbols with
* code == 0x0 && code >= 0x80)
* -# send encoded data to the server
* -# decode recieved characters with pg_client_to_server in
* src/backend/libpq/pqformat.c#pq_getmsgstring
* -# decode bytea C-string with byteain
* .
* and path for server->client transfer is:
* -# encode bytea into C-string with byteaout (encode in \\ooo form all symbols with
* !isprint(symbol code) for current server locale)
* -# encode query result characters with pq_server_to_client in
* src/backend/libpq/pqformat.c#pq_sendcountedtext
* -# send encoded data to the client
* -# decode recieved data with PQunescapeBytea
*
* If we have the next client-server configuration:
*
@verbatim
+-+
| KOI8 (ru_RU.KOI8-R) |
| |
| Server|
+--++-+
^|
||
|v
+--+--+ +--+
| KOI8 (ru_RU.KOI8-R) | | WIN (CP1251) |
| | | |
| Client (Linux)| | Client (Windows) |
+-+ +--+
@endverbatim
*
* then, for example, symbol RUSSIAN_A (code 255) from Linux-client will be translated
* in database into the symbol with code 255, and then for Windows client --- into the
* symbol with code 192, that is wrong for bytea data type
*
* In case when database has UNICODE encoding some parts of bytea strings from server
will
* not be even send to the client, because some symbol chains in current server locale
don't
* present valid utf8 sequence and can't be translated to client encoding properly.
*
* Simplest way to solve this problem is to replace isprint check in byteaout and
* >= 0x80 check in PQescapeBytea procedures with isascii && isprint checks, because
* ASCII symbols for all locales (and database encodings) have the same byte codes.
*
* Or you may do in byteaout the same symbol check as in PQescapeBytea (encode in \\ooo
* form all symbols with code >= 0x80).
*
* But I prefer first way (with isascii && isprint check in both byteaout and
PQesacpeBytea),
* because it produce nice printable and editable ASCII dump output for debug :-)).
*
* Test steps:
*-# compile program with command (for gcc 3.2.3):
* g++ -Wall -pedantic -I`pg_config --includedir` bytea-test.cxx -o
bytea-test -lpq
*-# init database cluster with non C(ASCII) locale (for example ru_RU.KOI8-R)
*-# create test database with non SQL_ASCII encoding (for example KOI8)
*-# create test table in this database with command: CREATE TABLE bytea_test
(data BYTEA);
*-# run test with command: ./bytea-test test.data
*-# try the three prevous steps with UNICODE database
*
* Then apply patches (at least varlena.c.diff) and run test again. All must be done
* successfully.
*
* @note @c bytea_test table must be available for deleting, inserting and selecting
*
* @note Attatched test file (test.data) contains sequence of all 256 8-bit symbols.
*
* @bug I am very sorry for my bad english, but I hope you understand me :-))
*/
#include
#include
#include
#include
#include
using namespace std;
int
main (int _argc, char **_argv) {
// Check arguments count
if (_argc != 3) {
cerr << "Usage: " << _argv[0] << " \n";
return 1;
}
// Set up the database connection
PGconn *conn = PQsetdb (NULL, NULL, NULL, NULL, _argv[1]);
if (PQstatus (conn) == CONNECTION_BAD) {
cerr << "Can't connect to database " << _argv[1] << " (" <<
PQerrorMessage (conn) << ")\n";
PQfinish (conn);
return 1;
}
// First client encoding
PQsetClientEncoding (conn, "KOI8");
if (PQstatus (conn) == CO
[BUGS] Probably a security bug in PostgreSQL rule system
At begin some citations from PostgreSQL documentation:
34.4. Rules and Privileges
Rewrite rules don't have a separate owner. The owner of a relation
(table or view) is automatically the owner of the rewrite rules that are
defined for it. The PostgreSQL rule system changes the behavior of the
default access control system. Relations that are used due to rules get
checked against the privileges of the rule owner, not the user invoking
the rule. This means that a user only needs the required
privileges for the tables/views that he names explicitly in his
queries.
This mechanism also works for update rules. In the examples
of the previous section, the owner of the tables in the example database
could grant the privileges SELECT, INSERT, UPDATE, and DELETE on the
shoelace view to someone else, but only SELECT on shoelace_log. The rule
action to write log entries will still be executed successfully, and
that other user could see the log entries. But he cannot create fake
entries, nor could he manipulate or remove existing ones.
Next -- test and it's output, that shows, that if view has INSERT,
UPDATE and DELETE rules then _ANY_ user can insert, update and delete
data in tables, that affected by this rules even user has no INSERT,
UPDATE and DELETE privileges on view and table.
This problem exists for at least 7.3.4 and 7.4.1 PostgreSQL versions.
This is very strange and I'm not sure that I understand all true.
P.S. Please help me solve this problem ASAP.
P.P.S. Sorry for my bad english, but I hope You understand me.
--
Sergey N. Yatskevich <[EMAIL PROTECTED]>
GosNIIAS
-- Test view/rule privileges
SET client_min_messages = ERROR;
\! echo "Show full PostgreSQL version."
SELECT version ();
\! echo "Create user with name user1"
CREATE USER user1;
\! echo "Create user with name user2"
CREATE USER user2;
\! echo
\! echo
\! echo "Switch to user1 with set session authrization"
SET SESSION AUTHORIZATION user1;
\! echo
\! echo "user1 creates private table with name user1_table"
CREATE TABLE user1_table (
id INTEGER PRIMARY KEY,
data TEXT
);
\! echo "and revokes all rights on it from public."
REVOKE ALL ON user1_table FROM PUBLIC;
\! echo "Next user1 creates private view for table user1_table with name user1_view"
\! echo "and appropriate insert, update and delete rules on it."
CREATE VIEW user1_view AS SELECT data FROM user1_table;
CREATE RULE user1_view_insert AS
ON INSERT TO user1_view
DO INSTEAD INSERT INTO user1_table
VALUES (COALESCE ((SELECT max (id) + 1 FROM user1_table), 0), new.data);
CREATE RULE user1_view_update AS
ON UPDATE TO user1_view
DO INSTEAD UPDATE user1_table SET data = new.data;
CREATE RULE user1_view_delete AS
ON DELETE TO user1_view
DO INSTEAD DELETE FROM user1_table;
\! echo "and revokes all rights on it from public."
REVOKE ALL ON user1_view FROM PUBLIC;
\! echo
\! echo
\! echo "Switch to user2 with set session authrization"
SET SESSION AUTHORIZATION user2;
\! echo
\! echo "user2 tries to select data from user1_table."
\! echo "Must be error becouse user2 don't have SELECT privilege"
\! echo "on user1_table and this is true. This is good."
SELECT * FROM user1_table;
\! echo
\! echo "user2 tries to insert data into user1_table."
\! echo "Must be error becouse user2 don't have INSERT privilege"
\! echo "on user1_table and this is true. This is good."
INSERT INTO user1_table VALUES (1, 'test data');
\! echo
\! echo "user2 tries to update data in user1_table."
\! echo "Must be error becouse user2 don't have UPDATE privilege"
\! echo "on user1_table and this is true. This is good."
UPDATE user1_table SET data = data || USER;
\! echo
\! echo "user2 tries to delete data from user1_table."
\! echo "Must be error becouse user2 don't have DELETE privilege"
\! echo "on user1_table and this is true. This is good."
DELETE FROM user1_table;
\! echo
\! echo "user2 tries to select data from user1_view."
\! echo "Must be error becouse user2 don't have SELECT privilege"
\! echo "on user1_view and this is true. This is good."
SELECT * FROM user1_view;
\! echo
\! echo "user2 tries to insert data into user1_view."
\! echo "Must be error becouse user2 don't have INSERT privilege"
\! echo "on user1_view but this is false. This is WRONG"
INSERT INTO user1_view VALUES ('test data');
\! echo
\! echo "user2 tries to update data in user1_view."
\! echo "Must be error becouse user2 don't have UPDATE privilege"
\! echo "on user1_view and this is true. This is good."
UPDATE user1_view SET data = data || USER;
\! echo
\! echo "user2 tries to delete data from user1_view."
\! echo "
[BUGS] Bug in ECPG preprocessor
ECPG preprocessor for PostgreSQL 7.4.1, 7.4.2 doubles const,
volatile, static, and register keywords before variables,
declared as VARCHAR.
I attach to this mail example for this, and patch for PostgreSQL
7.4.1, that solves this problem (this patch also applicable to
PostgreSQL 7.4.2 too)
--
Sergey N. Yatskevich <[EMAIL PROTECTED]>
GosNIIAS
start.sh
Description: application/shellscript
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
EXEC SQL INCLUDE sqlca;
EXEC SQL BEGIN DECLARE SECTION;
int n;
extern int i, y;
VARCHAR vc1[128];
extern VARCHAR vc2[128];
volatile VARCHAR vc3[128];
const VARCHAR vc4[128] = {10, "0123456789"};
unsigned char bt1[128];
extern unsigned char bt2[128];
unsigned char btout1[128];
extern unsigned char btout2[128];
unsigned int lbt, lbt1, lbt2;
int cint;
extern double cdouble;
EXEC SQL END DECLARE SECTION;
///
int main ( int argc, char *argv[] )
///
{
sprintf(vc1.arr,"varchar1");
printf("TEST: %s %s\n",vc1.arr,vc4.arr);
}
Index: src/interfaces/ecpg/preproc/preproc.y
===
RCS file: /mnt/disk/cvsroot/pgsql/src/interfaces/ecpg/preproc/preproc.y,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 preproc.y
--- src/interfaces/ecpg/preproc/preproc.y 25 Dec 2003 10:58:24 - 1.1.1.3
+++ src/interfaces/ecpg/preproc/preproc.y 24 May 2004 14:13:42 -
@@ -19,7 +19,6 @@
static int QueryIsRule = 0, FoundInto = 0;
static int initializer = 0;
static struct this_type actual_type[STRUCT_DEPTH];
-static char *actual_storage[STRUCT_DEPTH];
static char *actual_startline[STRUCT_DEPTH];
/* temporarily store struct members while creating the data structure */
@@ -4419,6 +4418,8 @@
actual_type[struct_level].type_dimension = $2.type_dimension;
actual_type[struct_level].type_index = $2.type_index;
actual_type[struct_level].type_sizeof = $2.type_sizeof;
+
+ actual_startline[struct_level] = hashline_number();
}
variable_list ';'
{
@@ -4430,7 +4431,6 @@
actual_type[struct_level].type_dimension = $1.type_dimension;
actual_type[struct_level].type_index = $1.type_index;
actual_type[struct_level].type_sizeof = $1.type_sizeof;
- actual_storage[struct_level] = EMPTY;
actual_startline[struct_level] = hashline_number();
}
@@ -4687,6 +4687,8 @@
actual_type[struct_level].type_dimension = $2.type_dimension;
actual_type[struct_level].type_index = $2.type_index;
actual_type[struct_level].type_sizeof = $2.type_sizeof;
+
+ actual_startline[struct_level] = hashline_number();
}
variable_list ';'
{
@@ -4698,7 +4700,6 @@
actual_type[struct_level].type_dimension = $1.type_dimension;
actual_type[struct_level].type_index = $1.type_index;
actual_type[struct_level].type_sizeof = $1.type_sizeof;
- actual_storage[struct_level] = EMPTY;
actual_startline[struct_level] = hashline_number();
}
@@ -4714,18 +4715,15 @@
storage_declaration: storage_clause storage_modifier
{
- actual_storage[struct_level] = cat2_str(mm_strdup($1), mm_strdup($2));
- actual_startline[struct_level] = hashline_number();
+ $$ = cat2_str ($1, $2);
}
| storage_clause
{
- actual_storage[struct_level] = mm_strdup($1);
- actual_startline[struct_level] = hashline_number();
+ $$ = $1;
}
| storage_modifier
{
- actual_storage[struct_level] = mm_strdup($1);
- actual_startline[struct_level] = hashline_number();
+ $$ = $1;
}
;
@@ -4951,7 +4949,7 @@
ECPGfree_struct_member(struct_member_list[struct_level]);
struct_member_list[struct_level] = NULL;
- free(actual_storage[struct_level--]);
+ struct_level--;
if (strncmp($1.su, "struct", sizeof("struct")-1) == 0)
su_type.type_enum = ECPGt_struct;
else
@@ -5001,7 +4999,7 @@
{
ECPGfree_struct_member(struct_member_list[struct_level]);
struct_member_list[struct_level] = NULL;
- free(actual_storage[struct_level--]);
+ struct_level--;
$$ = cat_str(4, $1, make_str("{"), $4, make_str("}"));
}
;
@@ -5126,9 +5124,9 @@
mmerror(PARSE_ERROR, ET_ERROR, "pointer to varchar are not implemented");
if (strcmp(dimension, "0") == 0)
- $$ = cat_str(7, mm_strdup(actual_storage[struct_level]), make2_str(make_str(" struct varchar_"), mm_strdup($2)), make_str(" { int len; char arr["), mm_strdup(length), make_str("]; } *"), mm_strdup($2), $4);
+ $$ = cat_str(6, make2_str(make_str(" struct varchar_"), mm_strdup($2)), make_str(" { int len; char arr["), mm_strdup(length), make_str("]; } *"
[BUGS] Bug in ALTER LANGUAGE ... RENAME TO ...;
RenameLanguage procedure in src/backend/commands/proclang.c open and update pg_catalog.pg_shadow table instead pg_catalog.pg_language. -- Sergey N. Yatskevich <[EMAIL PROTECTED]> diff -Naur postgresql-8.0.0/src/backend/commands/proclang.c postgresql-8.0.0.new/src/backend/commands/proclang.c --- postgresql-8.0.0/src/backend/commands/proclang.c 2005-01-01 00:59:41 +0300 +++ postgresql-8.0.0.new/src/backend/commands/proclang.c 2005-02-11 20:36:47 +0300 @@ -246,7 +246,7 @@ HeapTuple tup; Relation rel; - rel = heap_openr(ShadowRelationName, RowExclusiveLock); + rel = heap_openr(LanguageRelationName, RowExclusiveLock); tup = SearchSysCacheCopy(LANGNAME, CStringGetDatum(oldname), ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
