[BUGS] BUG #8237: CASE Expression - Order of expression processing
The following bug has been logged on the website: Bug reference: 8237 Logged by: Andrea Lombardoni Email address: and...@lombardoni.ch PostgreSQL version: 9.0.4 Operating system: Linux Description: I observed the following behaviour (I tested the following statements in 9.0.4, 9.0.5 and 9.3beta1): $ psql template1 template1=# SELECT CASE WHEN 0=0 THEN 0 ELSE 1/0 END; case -- 0 (1 row) template1=# SELECT CASE WHEN 1=0 THEN 0 ELSE 1/0 END; ERROR: division by zero In this case the CASE behaves as expected. But in the following expression: template1=# SELECT CASE WHEN (SELECT 0)=0 THEN 0 ELSE 1/0 END; ERROR: division by zero (Just to be sure, a "SELECT (SELECT 0)=0;" returns true) What I expect: template1=# SELECT CASE WHEN (SELECT 0)=0 THEN 0 ELSE 1/0 END; 0 template1=# SELECT CASE WHEN (SELECT 1)=0 THEN 0 ELSE 1/0 END; ERROR: division by zero It seems that when the "CASE WHEN expression" is a query, the evaluation order changes. According to the documentation, this behaviour is wrong. http://www.postgresql.org/docs/9.0/static/sql-expressions.html (4.2.13. Expression Evaluation Rules): "When it is essential to force evaluation order, a CASE construct (see Section 9.16) can be used. " http://www.postgresql.org/docs/9.0/static/functions-conditional.html (9.16.1. CASE): "If the condition's result is true, the value of the CASE expression is the result that follows the condition, and the remainder of the CASE expression is not processed." "A CASE expression does not evaluate any subexpressions that are not needed to determine the result." The discussion on postgresql-general ( http://www.postgresql.org/message-id/camq5dgq4sujpbht2-9xlapasvknul2-bb0cpyci2fp+pfsf...@mail.gmail.com ) also seems to indicate that this is a bug. At least it is a discrepancy between documentation and behaviour. -- 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 #4392: initdb doen't work with options -U username and -W
The following bug has been logged online: Bug reference: 4392 Logged by: Andrea Villardino Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.3 Operating system: windows server 2003(or vista) Description:initdb doen't work with options -U username and -W Details: if i do an installation with: msiexec /i "%PATH_DB_INSTALLER%postgresql-8.3-int.msi" /l*v %DB_INSTALL_DIR_LOG%postgres_install.log /qr INTERNALLAUNCH=1 ADDLOCAL=server,psql SERVICEDOMAIN=%COMPUTERNAME% SERVICEACCOUNT=%DB_SERVICE_ACCOUNT% SERVICEPASSWORD=%DB_SERVICE_PASSWORD% SUPERUSER=%DB_SUPERUSER_ACCOUNT% SUPERPASSWORD=%DB_SUPERUSER_PASSWORD% ENCODING=%DB_SERVER_ENCODING% LOCALE=%DB_SERVER_LOCALE% it works. But when I try to divede msiexec from inidb it doesn't work. In particular: "C:\\Program Files\\postgresql\\8.3\\bin\\initdb.exe" --pgdata="C:\\Program Files\\postgresql\\8.3\\data" --encoding=UNICODE --locale=C It works. But: "C:\\Program Files\\postgresql\\8.3\\bin\\initdb.exe" --pgdata="C:\\Program Files\\postgresql\\8.3\\data" --encoding=UNICODE --locale=C -U andrea -W Doesn't work because when i try to start up the postgres service there are a lot of error in the application event viewer saying: FATAL: role "postgres" does not exist Even if the inidb output is ok: C:\WINDOWS>"C:\\Program Files\\postgresql\\8.3\\bin\\initdb.exe" --pgdata="C:\\Program Files\\postgresql\\8.3\\data" --encoding=UNICODE --locale=C -U andrea -W The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale C. The default text search configuration will be set to "english". fixing permissions on existing directory C:/Program Files/postgresql/8.3/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers/max_fsm_pages ... 32MB/204800 creating configuration files ... ok creating template1 database in C:/Program Files/postgresql/8.3/data/base/1 ... ok initializing pg_authid ... ok Enter new superuser password: Enter it again: setting password ... ok initializing dependencies ... ok creating system views ... ok loading system objects' descriptions ... ok creating conversions ... ok creating dictionaries ... ok setting privileges on built-in objects ... ok creating information schema ... ok vacuuming database template1 ... ok copying template1 to template0 ... ok copying template1 to postgres ... ok WARNING: enabling "trust" authentication for local connections You can change this by editing pg_hba.conf or using the -A option the next time you run initdb. Success. You can now start the database server using: "C:\\Program Files\\postgresql\\8.3\\bin\postgres" -D "C:/Program Files/postgresql/8.3/data" or "C:\\Program Files\\postgresql\\8.3\\bin\pg_ctl" -D "C:/Program Files/postgresql/8.3/data" -l logfile start C:\WINDOWS> -- 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 #4391: initdb doen't work with options -U username and -W
The following bug has been logged online: Bug reference: 4391 Logged by: Andrea Villardino Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.3 Operating system: windows server 2003(or vista). Description:initdb doen't work with options -U username and -W Details: if i do an installation with: msiexec /i "%PATH_DB_INSTALLER%postgresql-8.3-int.msi" /l*v %DB_INSTALL_DIR_LOG%postgres_install.log /qr INTERNALLAUNCH=1 ADDLOCAL=server,psql SERVICEDOMAIN=%COMPUTERNAME% SERVICEACCOUNT=%DB_SERVICE_ACCOUNT% SERVICEPASSWORD=%DB_SERVICE_PASSWORD% SUPERUSER=%DB_SUPERUSER_ACCOUNT% SUPERPASSWORD=%DB_SUPERUSER_PASSWORD% ENCODING=%DB_SERVER_ENCODING% LOCALE=%DB_SERVER_LOCALE% it works. But when I try to divede msiexec from inidb it doesn't work. In particular: "C:\\Program Files\\postgresql\\8.3\\bin\\initdb.exe" --pgdata="C:\\Program Files\\postgresql\\8.3\\data" --encoding=UNICODE --locale=C It works. But: "C:\\Program Files\\postgresql\\8.3\\bin\\initdb.exe" --pgdata="C:\\Program Files\\postgresql\\8.3\\data" --encoding=UNICODE --locale=C -U andrea -W Doesn't work because when i try to start up the postgres service there are a lot of error in the application event viewer saying: FATAL: role "postgres" does not exist Even if the inidb output is ok: C:\WINDOWS>"C:\\Program Files\\postgresql\\8.3\\bin\\initdb.exe" --pgdata="C:\\Program Files\\postgresql\\8.3\\data" --encoding=UNICODE --locale=C -U andrea -W The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale C. The default text search configuration will be set to "english". fixing permissions on existing directory C:/Program Files/postgresql/8.3/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers/max_fsm_pages ... 32MB/204800 creating configuration files ... ok creating template1 database in C:/Program Files/postgresql/8.3/data/base/1 ... ok initializing pg_authid ... ok Enter new superuser password: Enter it again: setting password ... ok initializing dependencies ... ok creating system views ... ok loading system objects' descriptions ... ok creating conversions ... ok creating dictionaries ... ok setting privileges on built-in objects ... ok creating information schema ... ok vacuuming database template1 ... ok copying template1 to template0 ... ok copying template1 to postgres ... ok WARNING: enabling "trust" authentication for local connections You can change this by editing pg_hba.conf or using the -A option the next time you run initdb. Success. You can now start the database server using: "C:\\Program Files\\postgresql\\8.3\\bin\postgres" -D "C:/Program Files/postgresql/8.3/data" or "C:\\Program Files\\postgresql\\8.3\\bin\pg_ctl" -D "C:/Program Files/postgresql/8.3/data" -l logfile start C:\WINDOWS> -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] duplicate key violates unique contraint on pg_type_typname_nsp_index
Hi all, I'm running Postgresql 8.3.9 on debian lenny amd64 the box has 8GB of ram, the db runs on a separate software raid-1 device, that's the output of select version(); # SELECT version () ; version PostgreSQL 8.3.9 on x86_64-unknown-linux-gnu, compiled by GCC gcc (Debian 4.3.2-1.1) 4.3.2 (1 row) I'm experiencing something weird. here the session's log that involves the prob I mentioned 2010-03-08 12:58:53 CET p...@c[3189]error: table "check_unfitted_strata_col" does not exist 2010-03-08 12:58:53 CET p...@c[3189]statement: drop table check_unfitted_strata_col 2010-03-08 12:58:53 CET p...@c[3189]log: duration: 0.018 ms statement: Begin 2010-03-08 12:59:41 CET p...@c[3189]error: duplicate key value violates unique constraint "pg_type_typname_nsp_index" 2010-03-08 12:59:41 CET p...@c[3189]statement: create table check_unfitted_strata_col as select * from sampling.sample_gen_design limit 0 2010-03-08 12:59:41 CET p...@c[3189]log: duration: 0.016 ms statement: rollback as you can see firstly I try to drop the table check_unfitted_strata_col (search_path is set to default so the complete name is public.check_unfitted_strata_col) then I try to create a table with the very same name and fileds definition (I'm to emulate DROP IF EXISTS for backward compatibility). But for some reasons sometimes CREATE TABLE fails violate unique constraint on pg_type_typname_nsp_index... I googled around a bit but everything I find seems related to temp table, which is not my case :/ http://archives.postgresql.org/pgsql-novice/2004-11/msg00241.php http://markmail.org/message/iusg4626iwdcmrg2#query:+page:1+mid:iusg4626iwdcmrg2+state:results http://archives.postgresql.org/pgsql-general/2005-07/msg00412.php those sql commands could be executed in separate postgres back-ends almost simultaneously (isolation level is read committed), but I always thought wrapping the CREATE TABLE command inside a transaction avoid any misbehavior (a part from the fact that the second process will wait for the first to commit or rollback) am I missing something? (FWIW testing the same path using psql, emulating concurrent sessions did not raise any problems) it's worthy to note that the problem seems to goes away after restarting postgresql (the box is turned off during the night). The sql command are submitted by a tcl/tk applications that use a persistent connection via libpgtcl. Unfortunately I'm not able to set up a reproducible test-case :/ Andrea -- 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] duplicate key violates unique contraint on pg_type_typname_nsp_index
On 09/03/2010 16:51, Tom Lane wrote: Andrea Suisani writes: I'm experiencing something weird. here the session's log that involves the prob I mentioned 2010-03-08 12:59:41 CET p...@c[3189]error: duplicate key value violates unique constraint "pg_type_typname_nsp_index" 2010-03-08 12:59:41 CET p...@c[3189]statement: create table check_unfitted_strata_col as select * from sampling.sample_gen_design limit 0 those sql commands could be executed in separate postgres back-ends almost simultaneously (isolation level is read committed), but I always thought wrapping the CREATE TABLE command inside a transaction avoid any misbehavior (a part from the fact that the second process will wait for the first to commit or rollback) Well, it does avoid any "misbehavior", it's just not producing exactly the error message you expect. If you have two sessions trying to create the same table name at exactly the same time, this is a likely result. I'm not 100% sure but it's quite unlikely that they try to create the table at exactly the same time. With "almost simultaneously" I meant to indicate some kind of time overlapping between the two session. They both have to create pg_type entries for the table's row type, so they can collide on that as well as on the table name itself. take for granted the "at exactly same time" hypothesis, it does maks sense. just after I've sent the email I've checked to which table pg_type_typname_nsp_index belongs to and found that pg_type's the "owner" There have been some unexplained reports of similar error messages in cases where it didn't seem that any concurrent creation could be going on. But I don't see any reason to think there's anything very mysterious here, if you do have sessions trying to create the same table concurrently. I will dig deeper and I'll try to monitor the process for the next few days trying to get more infos. I'll keep you posted thanks Andrea -- 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] duplicate key violates unique contraint on pg_type_typname_nsp_index
On 09/03/2010 17:12, Andrea Suisani wrote: On 09/03/2010 16:51, Tom Lane wrote: Andrea Suisani writes: I'm experiencing something weird. here the session's log that involves the prob I mentioned 2010-03-08 12:59:41 CET p...@c[3189]error: duplicate key value violates unique constraint "pg_type_typname_nsp_index" 2010-03-08 12:59:41 CET p...@c[3189]statement: create table check_unfitted_strata_col as select * from sampling.sample_gen_design limit 0 those sql commands could be executed in separate postgres back-ends almost simultaneously (isolation level is read committed), but I always thought wrapping the CREATE TABLE command inside a transaction avoid any misbehavior (a part from the fact that the second process will wait for the first to commit or rollback) Well, it does avoid any "misbehavior", it's just not producing exactly the error message you expect. If you have two sessions trying to create the same table name at exactly the same time, this is a likely result. I'm not 100% sure but it's quite unlikely that they try to create the table at exactly the same time. scratch that :/ $ zgrep -C1 'duplicate key value violates unique constraint "pg_type_typname_nsp_index"' postgresql-8.3.log.2 2010-03-08 12:59:41 CET p...@c[7839]error: duplicate key value violates unique constraint "pg_type_typname_nsp_index" 2010-03-08 12:59:41 CET p...@c[7839]statement: create table check_unfitted_strata_col as select * from sampling.sample_gen_design limit 0 2010-03-08 12:59:41 CET p...@c[3189]error: duplicate key value violates unique constraint "pg_type_typname_nsp_index" 2010-03-08 12:59:41 CET p...@c[3189]statement: create table check_unfitted_strata_col as select * from sampling.sample_gen_design limit 0 after a better parsing of the log I changed my mind it's *quite likely* they were trying to create the table at exactly the same time. sorry for the noise. thanks Andrea -- 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
To report any other bug, fill out the form below and e-mail it to [EMAIL PROTECTED] POSTGRESQL BUG REPORT TEMPLATE Your name : Andrea Baldoni Your email address : [EMAIL PROTECTED] System Configuration - Architecture : Intel Pentium III 500 Operating System : Linux 2.4.0-test10 (same problem on 2.2.17), debian 2.2 PostgreSQL version: PostgreSQL-6.5.2 Compiler used : gcc version 2.95.2 2313 Please enter a FULL description of your problem: Creating tables (temp or normal) inside a transaction sometime fails, ending with corruption in pg_attribute system data table (if I do "select * from pg_attribute" the server crash). If I stop and restart the server the problem remains... I must restore pg_attribute* files to make things working. The file having the name of the table created sometime remains in the file system. Debug output: . . pq_flush: send() failed: Bad file descriptor pq_flush: send() failed: Bad file descriptor pq_recvbuf: recv() failed: Bad file descriptor ERROR: infinite recursion in proc_exit pq_flush: send() failed: Bad file descriptor NOTICE: AbortTransaction and not in in-progress state pq_flush: send() failed: Bad file descriptor pq_flush: send() failed: Bad file descriptor pq_recvbuf: recv() failed: Bad file descriptor ERROR: infinite recursion in proc_exit . . Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- I'm using many script like this one, accessing different tables, and I haven't found differences. Sample bash script: #!/bin/bash umask 077 cat << EOF |psql abaldoni 2> /dev/null > /tmp/$0$$ begin transaction; create temp table excontitmp0 ( id_documento integer, totale real ); create temp table excontitmp1 ( id_documento integer, totale real ); create temp table excontitmp2 ( numerario integer ); insert into excontitmp2 select numerario from conti_desc where capoconto=$1 and sottoconto=$2; insert into excontitmp0 select id_documento, sum(importo) as totale from conti where capo_da=$1 and sotto_da=$2 and documenti.data>='01/01/2000' and id_documento=documenti.id group by id_documento; insert into excontitmp0 select id_documento, -sum(importo) as totale from conti where capo_a=$1 and sotto_a=$2 and documenti.data>='01/01/2000' and id_documento=documenti.id group by id_documento; insert into excontitmp1 select id_documento, sum(totale) as totale from excontitmp0 group by id_documento; select id_documento, documenti.data, ditte.ragione_sociale, totale*(1-excontitmp2.numerario*2) from excontitmp1 where ditte.id=documenti.id_clifor and documenti.id=id_documento order by documenti.data, id_documento; select sum(totale*(1-excontitmp2.numerario*2)) as totale from excontitmp0; commit transaction; EOF less /tmp/$0$$ rm /tmp/$0$$ If you know how this problem might be fixed, list the solution below: - Ciao, AB
Re: [BUGS] PostgreSQL 7.0.2 Date Miscalculation
On Tue, Apr 03, 2001 at 12:59:31AM -0400, Tom Lane wrote: > However, the horology diffs are not, and I can't reproduce them here. > Did anyone else see that? me too (the problem started in these days) ciao, andrea ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[BUGS] ehm...
well, i will be a little verbose, but i am afraid this could be a big bug in postgresql, so... i've made a script in python that, by psycopg module, put freecddb archive in a relational db. so, it does a few select and a lot of insert for each file of freecddb (something like 500.000 files). now, the process is slower (most of the time is spent reading small file, parsing and generating the right query), so i have try it just 8 times, and now i need to know if i am wrong or if is it a real postgresql problem (having see the problem of duplicated key, and so on). well, just to make this a little bit more a bug report: os: linux 2.4.18pre1 (also tried with 2.4.17) distribution: debian unstable gcc: gcc version 3.0.3 (also tried with 3.0.2) python: 2.1 psycopg: http://packages.debian.org/unstable/non-us/python2.1-psycopg.html postgresql: different cvs version in last 8 days now, what happen is simple: i run my script and after a lot of insert (the error in the bottom appears after 76242 file parsed), if i run vacuumdb i've got different error. i.e.: vacuumdb -a -v -f -z NOTICE: Analyzing author FATAL 2: open of /home/postgres/db/pg_clog/ failed: No such file or directo ry server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. connection to server was lost vacuumdb: vacuum freecddb failed i've got errors like this using vacuum with and without '-f', with db working and with db doing nothing else than vacuum. sometimes i've got errors of duplicated key (already know problem), but that time i didn't 'cut & paste' the error believing it was my fault by some mistake in my schema. now, i can investigate deeply, but i need your opinion if it is something to do or not. as i said, it takes longer to reproduce this (and maybe i'm doing something wrong). thanks a lot for your work, andrea n.b.: well, if i try on the same postgres to run other db i've got no problem, but they are a lot smaller and have a few read access and less write access per day (3-4 insert, without foreing keys, and one hundred select). ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] ehm...
On ven, gen 11, 2002 at 01:56:12 -0500, Tom Lane wrote: > Yup, it looks like a bug to me. Apparently a CLOG segment has been > recycled too soon. We just found a bug of that ilk in sequence > processing, but VACUUM doesn't touch sequences, so apparently you have > a different bug. Please submit details. yes, i will retry tonight. what kind of info do you want? by the way i can give you script and the rest of things you need (and it will be very easily for you to reproduce the problem... the script is very simple, and schema is nothing more than a few tables). > If you don't mind doing an initdb, you could reduce the CLOG segment no problem, i do initdb everytime I recompile cvs... > size to make it easier to try to reproduce the problem. In > src/backend/access/transam/clog.c change > #define CLOG_XACTS_PER_SEGMENT0x10 > to 0x1 (I think that's about as small as you can make it without > breaking anything). That gives you a shot at a problem every 64K > transactions. thanks for your time, andrea ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] ehm...
On ven, gen 11, 2002 at 03:16:12 -0500, Tom Lane wrote: > Yes, I would like a copy of your script. i will package script and 'instructions' soon. i've got also two snapshots of db after the crash (tar files of postgres directory) > > I just found and fixed a problem that could lead to this kind of failure > (reference to an already-deleted CLOG entry). However, I'm not sure yesterday i spent the afternoon doing a lot of test... now, i think you don't need the details because... > that the problem I fixed could affect VACUUM itself. Please update from you was right, and there's no need of vacuum db to crash the postmaster... doing a fresh installation, a fresh initdb, starting my script (and a second bash script that does nothing more than a simple insert) after about 1 milion transactions i can see the problem (after changed sources as you told me), without vacuumdb. > cvs (make sure you get src/backend/utils/time/tqual.c v 1.46) and then > see if you still see the problem. If you do, a backtrace from the point > where elog() is called would be really helpful. tomorrow i will redo all my tests, but i guess now the bug is fixed. thanks a lot for your work, andrea n.b.: when you'll come in italy i'll be happy to be your host... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] ehm...
On dom, gen 13, 2002 at 11:30:08 -0500, Tom Lane wrote: > Hm, you never did a VACUUM at all? Don't see how that can be --- > removal of CLOG segments is triggered by VACUUM. uhm... i was sure i didn't do vacuum... but... well... so I made other tests. > > Please let me know if you can still see the problem with today's snapshot. i've tried in these days, and it seems everything work right now... thanks a lot for your time, andrea ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] problem with date cast
hi all,
with latest cvs version of pg i've found this problem:
ns:/tmp> createdb gino
CREATE DATABASE
ns:/tmp> psql gino
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
gino=# create table test (date date, timestamp timestamp);
CREATE TABLE
gino=# insert into test values ('now','now');
INSERT 32101 1
gino=# \x
Expanded display is on.
gino=# select *,date::date as right,timestamp::date as wrong from test ;
-[ RECORD 1 ]-
date | 27/05/2002
timestamp | 27/05/2002 18:17:30,577187
right | 27/05/2002
wrong | 01/01/2000
am i missing something?
some info:
Linux ns 2.4.18-pre9-ac4 #1 lun feb 18 14:24:51 CET 2002 i686 unknown
debian (sid)
PostgreSQL 7.3devel on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.1
(Debian)
all regression tests passed.
thanks a lot for your work,
andrea gelmini
--
Jesus died for your sins. Make it worth his time.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] error in docs
Hi all,
I'm in trouble with examples in
http://www.postgresql.org/docs/7.3/interactive/arrays.html.
Step by step:
-cut here---
[EMAIL PROTECTED]:~$ createdb test
CREATE DATABASE
[EMAIL PROTECTED]:~$ psql test
Welcome to psql 7.3.3, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
test=# CREATE TABLE sal_emp (
test(# nametext,
test(# pay_by_quarter integer[],
test(# scheduletext[][]
test(# );
CREATE TABLE
test=# INSERT INTO sal_emp
test-# VALUES ('Bill',
test(# '{1, 1, 1, 1}',
test(# '{{"meeting", "lunch"}, {}}');
INSERT 44628 1
test=#
test=# INSERT INTO sal_emp
test-# VALUES ('Carol',
test(# '{2, 25000, 25000, 25000}',
test(# '{{"talk", "consult"}, {"meeting"}}');
INSERT 44629 1
test=# SELECT name FROM sal_emp WHERE pay_by_quarter[1] <>
pay_by_quarter[2];
name
---
Carol
(1 row)
test=# SELECT pay_by_quarter[3] FROM sal_emp;
pay_by_quarter
1
25000
(2 rows)
test=# SELECT schedule[1:2][1:1] FROM sal_emp WHERE name = 'Bill';
schedule
--
{{meeting},{""}}
(1 row)
test=# SELECT schedule[1:2][1] FROM sal_emp WHERE name = 'Bill';
schedule
--
{{meeting},{""}}
(1 row)
test=# UPDATE sal_emp SET pay_by_quarter = '{25000,25000,27000,27000}'
test-# WHERE name = 'Carol';
UPDATE 1
test=# UPDATE sal_emp SET pay_by_quarter[4] = 15000
test-# WHERE name = 'Bill';
UPDATE 1
test=# UPDATE sal_emp SET pay_by_quarter[1:2] = '{27000,27000}'
test-# WHERE name = 'Carol';
UPDATE 1
test=#
test=# CREATE TABLE tictactoe (
test(# squares integer[3][3]
test(# );
CREATE TABLE
test=#
test=# SELECT array_dims(schedule) FROM sal_emp WHERE name = 'Carol';
array_dims
[1:2][1:1]
(1 row)
test=# SELECT * FROM sal_emp WHERE pay_by_quarter[1] = 1 OR
test-# pay_by_quarter[2] = 1 OR
test-# pay_by_quarter[3] = 1 OR
test-# pay_by_quarter[4] = 1;
name | pay_by_quarter | schedule
--+---+--
Bill | {1,1,1,15000} | {{meeting},{""}}
(1 row)
test=# SELECT * FROM sal_emp WHERE pay_by_quarter[1:4] *= 1;
ERROR: Unable to identify an operator '*=' for types 'integer[]' and 'integer'
You will have to retype this query using an explicit cast
---cut here--
Well, Debian Sid, with these packages installed:
ii postgresql 7.3.3-1 Object-relational SQL database, descended from
POSTGRES
ii postgresql-client 7.3.3-1 Front-end programs for PostgreSQL
ii postgresql-dev 7.3.3-1 Header files for libpq (postgresql library)
ii postgresql-doc 7.3.3-1 Documentation for the PostgreSQL database
Thanks a lot for your work,
Andrea Gelmini
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[BUGS] pg_clog problem (maybe)...
The problem: 1) I create a stupid function like: CREATE FUNCTION p4() RETURNS integer AS ' BEGIN FOR i IN 1..100 LOOP insert into info values (random(),random()); END LOOP; RETURN 1; END; ' LANGUAGE plpgsql; 2) I create a new db and run "select p4();" 3) I open three connection to the same db and start operation as "begin work; select p4(); update info set data=RANDOM();commit;" "create index gino on info(x);" "begin work; update info set data=RANDOM();" Well, db schema is nothink more than this: create table info(meta text, data text, id serial primary key); 4) after a lot of work/insert I've got this: LOG: recycled transaction log file "000200B0" LOG: recycled transaction log file "000200B2" LOG: recycled transaction log file "000200B3" ERROR: could not access status of transaction 859388209 DETAIL: open of file "/home/gelma/pg4/bin/../db/pg_clog/0333" failed: No such file or directory ERROR: could not access status of transaction 859388209 DETAIL: open of file "/home/gelma/pg4/bin/../db/pg_clog/0333" failed: No such file or directory siae=# ERROR: could not access status of transaction 859388209 DETAIL: open of file "/home/gelma/pg4/bin/../db/pg_clog/0333" failed: No such file or directory I can reproduce this over and over... The real problem is my configuration: a linux unstable kernel with a debian unstable branch in a shiny new laptop (with no more test than a memtest86). Everything else seems working well, of course it doesn't mean it's not my fault. Anyway, I write to you asking: a) do you think it could be a problem of 7.4beta2 (not a problem of mine)? I remember Tom solved something like this years ago. b) if so, can you show me next steps to narrow down the problem to give you a little help? Thanks a lot for your work, Andrea Gelmini ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] SOLARIS 9 ULTRASPARC BUILD
hello, attached are the regression.out and regression.diffs files from make check on a Ultra 2 dual 300MHz CPU running Solaris 9 OS. Looks like no errorbut the expected due to difference in fp results. regression.diffs Description: Binary data regression.out Description: Binary data ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] SOLARIS 9 ULTRASPARC BUILD
hello all, this is the output as asked by Tom Lane. test8=> \set VERBOSITY verbose test8=> SELECT 'infinity'::float4; float4 -- Infinity (1 row) test8=> SELECT 'infinity'::float4; ERROR: 22P02: invalid input syntax for type real: "infinity" LOCATION: float4in, float.c:330 Following what Michael Fuhr reported about bug fix in Solaris 10 I'll try to build and test asap on a Ultra 250 dual 400MHz CPU installed with Solaris 10 beta. Anyways I can't do it before Aug 23 . As soon as I build I'll run the test and post the results here. Andre ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] Postgres 8.0.0b1 build on Solaris 10 Ultrasparc
hello all, here follows the regression test run on postgres 8.0.0b1. Hardware Ultra 2 dual 300MHz CPUS 768MB RAM OS Solaris 10 b 5 -- == creating temporary installation== == initializing database system == == starting postmaster== running on port 65432 with pid 15380 == creating database "regression" == CREATE DATABASE ALTER DATABASE == dropping regression test user accounts == == installing PL/pgSQL== == running regression test queries== parallel group (13 tests): boolean char text varchar name int4 int8 oid int2 float4 bit float8 numeric boolean ... ok char ... ok name ... ok varchar ... ok text ... ok int2 ... ok int4 ... ok int8 ... ok oid ... ok float4 ... ok float8 ... ok bit ... ok numeric ... ok test strings ... ok test numerology ... ok parallel group (20 tests): point lseg path box circle polygon timetz time date interval abstime tinterval timestamp comments reltime inet timestamptz type_sanity oidjoins opr_sanity point... ok lseg ... ok box ... ok path ... ok polygon ... ok circle ... ok date ... ok time ... ok timetz ... ok timestamp... ok timestamptz ... ok interval ... ok abstime ... ok reltime ... ok tinterval... ok inet ... ok comments ... ok oidjoins ... ok type_sanity ... ok opr_sanity ... ok test geometry ... ok test horology ... ok test insert ... ok test create_function_1... ok test create_type ... ok test create_table ... ok test create_function_2... ok test copy ... ok parallel group (7 tests): create_aggregate create_operator triggers vacuum constraints inherit create_misc constraints ... ok triggers ... ok create_misc ... ok create_aggregate ... ok create_operator ... ok inherit ... ok vacuum ... ok parallel group (2 tests): create_view create_index create_index ... ok create_view ... ok test sanity_check ... ok test errors ... ok test select ... ok parallel group (18 tests): select_into select_having select_distinct_on select_distinct case union aggregates random update select_implicit transactions namespace hash_index join arrays btree_index portals subselect select_into ... ok select_distinct ... ok select_distinct_on ... ok select_implicit ... ok select_having... ok subselect... ok union... ok case ... ok join ... ok aggregates ... ok transactions ... ok random ... ok portals ... ok arrays ... ok btree_index ... ok hash_index ... ok update ... ok namespace... ok test privileges ... ok test misc ... ok parallel group (5 tests): portals_p2 select_views cluster rules foreign_key select_views ... ok portals_p2 ... ok rules... ok foreign_key ... ok cluster ... ok parallel group (14 tests): limit temp sequence truncate polymorphism copy2 prepare conversion rangefuncs domain rowtypes without_oid plpgsql alter_table limit... ok plpgsql ... ok copy2... ok temp ... ok domain ... ok rangefuncs ... ok prepare ... ok without_oid ... ok conversion ... ok truncate ... ok alter_table ... ok sequence ... ok polymorphism ... ok rowtypes ... ok test stats... ok test tablespace ... ok == shutting down postmaster == postmaster stopped == All 96 tests passed. == rm regress.o make[2]: Leaving directory `/export/DATA/BUI
[BUGS] Not a real bug, but an error
Hi, I've just upgraded Roma 7.3.x to 7.4.5 on a Mandrake 10.1 community. I've used pg_dumpall (Roma version 7.4.5) to dump my previous databases to a file in plain text form and then trend to restore using 'psql -f'. But there was an error: a function needed in a constraint of a table was placed after the table definition! So it was impossible to create the table! It was just a matter to edit the file and cut and copy the function definition in the right place, drop the database and run the file again, but it could be a good idea to find a workaround. Actually, I had to dump the schema and data separately, as one file was to big to manage, but it was just a matter of confort. Thank for the great work. Postgresql is really a wonderfull thing. Andrea from Italy ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] SELECT FOR UPDATE and LIMIT 1 behave oddly
hi! Josh Berkus wrote: > Bruce, > [snip] > > > Well, limit+for update can be useful under some circumstances, as long as you > understand its limitations.We found a workaround. i'm sorry for the curiosity but could you share, if it's possible, this workaround? ;) andrea ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] SELECT FOR UPDATE and LIMIT 1 behave oddly
tnks for the hint ;) I'll try something similar here. Andrea Josh Berkus wrote: Andrea, i'm sorry for the curiosity but could you share, if it's possible, this workaround? ;) (if it's not the one you describe at the beginning thread e.g. don't use LIMIT 1) Well, we actually roped in the pg_locks view to do a "SELECT the first row not already locked for update".Then added some code on the client end for error handling, like race conditions and no rows being returned, both of which happen in production. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] pg_dump or hardware?
Hi all, short summary: platform: i386 SMP (dual PIII) os: linux 2.6.8.1 vendor: debian (3.1, stable) pgsql ver: 7.4.7 (deb) disk: tech. SCSI vendor. IBM model. DDYS-T36950N rev. S96H controller: adaptec aic-7892a description: we're experiencing a weird problem trying to get a dump of our db for backup purposes, the executed command is: /usr/bin/pg_dump -U postgres -h 6pali elenco | /usr/bin/bzip2 > elenco_test.bz2 the output: pg_dump: ERROR: could not open relation with OID 201327173 pg_dump: SQL command to dump the contents of table "nominativi" failed: PQendcopy() failed. pg_dump: Error message from server: ERROR: could not open relation with OID 201327173 pg_dump: The command was: COPY public.nominativi (nome_cogno, indirizzo, cap, citta, prov, prefisso, telefono1, telefono2, note, idpersona, estrazione, num_estra, occupato, cod_prov, cod_com, cod_reg, capoluo, rand) TO stdout; so it seems that we've got some problems with the "nominativi" table (a 20 million-row table), in fact the following command also fails: pg_dump -t nominativi -U postgres -h 6pali elenco | /usr/bin/bzip2 > nominativi.bz2 with the same err msg as before. Before the erros occurs we're are able to get a partial backup, see: #> ls -l nominativi.bz2 -rw-r--r--1 sickpig users2.5M apr 19 12:35 nominativi.bz2 #> wc -l nominativi 145904 nominativi We're trying to understand whether this is due to data corruption or hardware failure. We run long self-tests on our SCSI disk through smartmontools on a regular basis. see attached file for "smartctl -a /dev/sda" output. All suggestions are welcome. Regards, Andrea smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/ Device: IBM DDYS-T36950N Version: S96H Serial number: 5FFL3272 Device type: disk Transport protocol: Fibre channel (FCP-2) Local Time is: Wed Apr 19 13:14:01 2006 CEST Device supports SMART and is Enabled Temperature Warning Disabled or Not Supported SMART Health Status: OK Current Drive Temperature: 41 C Drive Trip Temperature:85 C Manufactured in week 06 of year 2001 Current start stop count: 147 times Recommended maximum start stop count: 1 times Error counter log: Errors CorrectedTotal Total Correction Gigabytes Total delay: [rereads/errors algorithm processed uncorrected minor | major rewrites] corrected invocations [10^9 bytes] errors read: 00 0 5 5 6628.657 0 write: 00 0 0 0 4231.306 0 Non-medium error count:0 SMART Self-test log Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ] Description number (hours) # 1 Background long Completed - 22800 - [- --] # 2 Background long Completed - 22631 - [- --] # 3 Background long Completed - 22463 - [- --] # 4 Background long Completed - 22294 - [- --] # 5 Background long Completed - 22126 - [- --] # 6 Background long Completed - 21958 - [- --] # 7 Background long Completed - 21789 - [- --] # 8 Background long Completed - 21621 - [- --] # 9 Background long Completed - 21452 - [- --] #10 Background long Completed - 21284 - [- --] #11 Background long Completed - 21115 - [- --] #12 Background long Completed - 20947 - [- --] #13 Background long Completed - 20801 - [- --] #14 Background long Completed - 20633 - [- --] #15 Background long Completed - 20464 - [- --] #16 Background long Completed - 20296 - [- --] #17 Background long Completed - 20127 - [- --] #18 Background long Completed - 19959 - [- --] #19 Background long Completed - 19790 - [- --] #20 Background long Completed - 19622 - [- --] Long (extended) Self Test duration: 1340 seconds [22.3 minutes] ---(end of broadcast)--- TIP 9: In versions belo
Re: [BUGS] pg_dump or hardware?
Thanks for the quick reply
Tom Lane wrote:
andrea suisani <[EMAIL PROTECTED]> writes:
[cut]
Hmm ... what do you get from
select oid from pg_class where relname = 'nominativi';
oid
561644
(1 row)
afaics it seems weird does this mean that another postgresql
object screw up? this is the "\d nominativi" output:
Table "public.nominativi"
Column | Type | Modifiers
+--+---
nome_cogno | character(70)|
indirizzo | character(40)|
cap| character(5) |
citta | character(35)|
prov | character(2) |
prefisso | character(4) |
telefono1 | character(13)|
telefono2 | character(13)|
note | character(100) |
idpersona | integer |
estrazione | date |
num_estra | integer |
occupato | boolean |
cod_prov | integer |
cod_com| integer |
cod_reg| integer |
capoluo| integer |
rand | double precision |
Indexes:
"citta1_idx" btree (prov, citta) WHERE (((prov = 'BL'::bpchar) OR (prov =
'PD'::bpchar) OR (prov = 'RO'::bpchar) OR (prov = 'VE'::bpchar) OR (prov = 'TV'::bpchar)
OR (prov = 'VR'::bpchar)) AND (cod_com IS NULL))
"cod_com_ndx1" btree (cod_com)
"codprov_capo_rand1" btree (cod_prov, capoluo, rand)
"pre_tel_index1" btree (prefisso, telefono1)
and none of nominativi's indexes has an oid like 201327173
select oid
from pg_class
where relname in
('citta1_idx','cod_com_ndx1','codprov_capo_rand1','pre_tel_index1');
oid
--
46788374
40916657
40916656
40916658
(4 rows)
select relname from pg_class where oid = 201327173;
relname
-
(0 rows)
while if I "ask" for oid 561644 this is what I get:
select relname from pg_class where oid = 561644;
relname
nominativi
(1 row)
If the first returns 201327173 while the second doesn't return anything,
then I'd wonder about corruption of pg_class's OID index. REINDEXing it
might help.
I don't remember whether 7.4 makes you use a standalone
backend to reindex system catalogs --- see its REINDEX man page for
details.
from what I can see from REINDEX man page, I can reindex shared system catalogs
in stand-alone mode
[cut]
Regards,
Andrea
---(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] Postgres 9.0 crash on win7
Hi, I'm using usually Postgres 8.4.4 (32bit) + Postgis 1.5.1 on Windows7 64bit. Now I try-ing the last Postgres 9.0 (32bit) + Postgis 1.5.2 on the same machine (win7 64bit). I experience a crash of Postgres while it is running a huge load of data. This is the report of log. 2010-10-01 22:38:55 CEST LOG: last completed transaction was at log time 2010-10-01 22:23:51.389+02 2010-10-01 22:38:56 CEST LOG: autovacuum launcher started 2010-10-01 22:38:56 CEST LOG: database system is ready to accept connections 2010-10-01 22:44:20 CEST LOG: server process (PID 2540) was terminated by exception 0xC005 2010-10-01 22:44:20 CEST HINT: See C include file "ntstatus.h" for a description of the hexadecimal value. 2010-10-01 22:44:20 CEST LOG: terminating any other active server processes 2010-10-01 22:44:20 CEST WARNING: terminating connection because of crash of another server process 2010-10-01 22:44:20 CEST 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. 2010-10-01 22:44:20 CEST HINT: In a moment you should be able to reconnect to the database and repeat your command. 2010-10-01 22:44:20 CEST WARNING: terminating connection because of crash of another server process 2010-10-01 22:44:20 CEST 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. 2010-10-01 22:44:20 CEST HINT: In a moment you should be able to reconnect to the database and repeat your command. 2010-10-01 22:44:20 CEST LOG: all server processes terminated; reinitializing 2010-10-01 22:44:31 CEST FATAL: pre-existing shared memory block is still in use 2010-10-01 22:44:31 CEST HINT: Check if there are any old server processes still running, and terminate them. The tablespace where I load the data is new create from postgres9.0 After seeing this. I try load the same data load procedure (on the same windows machine) using the postgres 8.4.4 istance and all terminated without any problem. The procedure is substantially only a huge list of string sql like insert into() executed one by one in many tables and with autocommit. Andrea Peri. -- ----- Andrea Peri . . . . . . . . . qwerty àèìòù -
Re: [BUGS] Postgres 9.0 crash on win7
:48:50.977+02
2010-10-03 10:51:00 CEST LOCATION: StartupXLOG,
.\src\backend\access\transam\xlog.c:6258
2010-10-03 10:51:00 CEST FATAL: 57P03: the database system is starting up
2010-10-03 10:51:00 CEST LOCATION: ProcessStartupPacket,
.\src\backend\postmaster\postmaster.c:1818
2010-10-03 10:51:01 CEST LOG: 0: autovacuum launcher started
2010-10-03 10:51:01 CEST LOCATION: AutoVacLauncherMain,
.\src\backend\postmaster\autovacuum.c:404
2010-10-03 10:51:01 CEST LOG: 0: database system is ready to accept
connections
2010-10-03 10:51:01 CEST LOCATION: reaper,
.\src\backend\postmaster\postmaster.c:2402
end of log
>Can you show your schema - the definition of the table(s) involved in the
INSERT and any triggers on them? The output of:
>
>\d+ tablename
>
>from psql would do the trick.
If you like I can send you the script.
It create may tables and start to populate using many inserts.
The real script is more big then this, but this 10mbytes is sufficient to
crash PG9.
However the main table involved is this:
Table
"public.linee_elementari"
Column | Type|
Modifiers| Storage | Description
---+---++--+-
codlinea | character varying(35) | not
null | extended |
codctr| character varying(35)
|| extended
|
codvisibilita | character varying(35)
|| extended
|
codbreakline | character varying(35)
|| extended
|
codclasse | character varying(35)
|| extended
|
codlatovestizione | character varying(35)
|| extended
|
codoriginelinea | character varying(35)
|| extended
|
codmodifica | character varying(35)
|| extended
|
poslist | character varying(20)
|| extended
|
lung_poslist | integer
|| plain
|
num_vertex| integer
|| plain
|
idedge| character varying(35)
|| extended
|
srsname | character varying(35)
|| extended
|
dimension | character varying(1)
|| extended
|
coord_n1 | character varying(50)
|| extended
|
coord_n2 | character varying(50)
|| extended
|
geom | geometry
|| main
|
oid | integer | not null default
nextval('linee_elementari_oid_seq'::regclass) | plain|
Indexes:
"linee_elementari_pkey" PRIMARY KEY, btree (codlinea)
Check constraints:
"enforce_dims_geom" CHECK (st_ndims(geom) = 2)
"enforce_geotype_geom" CHECK (geometrytype(geom) = 'LINESTRING'::text OR
geom IS NULL)
"enforce_srid_geom" CHECK (st_srid(geom) = 3003)
Has OIDs: no
>Truly, the most helpful thing at this point would be to collect a backtrace
showing where in the postgresql server it crashed. There are instructions on
how to do that here:
>
>http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows<http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows>
>
>In your case, as the backend is crashing you will want to use windbg or
Visual Studio Express Edition to collect the crash data; process explorer
will not be enough.
ok, now I try to do this backtrace.
Regards,
Andrea.
2010/10/3 Craig Ringer
> On 2/10/2010 9:08 PM, Andrea Peri wrote:
>
>> Hi,
>>
>> I'm using usually
>> Postgres 8.4.4 (32bit) + Postgis 1.5.1 on Windows7 64bit.
>>
>> Now I try-ing the last
>> Postgres 9.0 (32bit) + Postgis 1.5.2 on the same machine (win7 64bit).
>>
>> I experience a
>>
>> crash of Postgres while it is running a huge load of data.
>>
>
> Does that include PostGIS datatyp
Re: [BUGS] BUG #6303: ROW_NUMBER()
On 11/21/2011 06:42 PM, bricklen wrote: On Mon, Nov 21, 2011 at 8:40 AM, Alessandro Bellanda wrote: The following bug has been logged online: Bug reference: 6303 Logged by: Alessandro Bellanda Email address: a.bella...@gmail.com PostgreSQL version: 9.1.1 Operating system: Linux CentOS release 5.5 64 bit Description:ROW_NUMBER() Details: Case: ROW_NUMBER() OVER (ORDER BY CASE(SUM(expr1)>SUM(expr2),var1,var2)) Error description: could not find pathkey item to sort Tom Lane has already fixed this. See http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1679e9feddc94bd7372a6829db92868e55ef7177 and the fix will be included into postgres 9.1.2 (that should be announced on Monday Dec 5, with tarballs available from Thursday Dec 1) Andrea -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
The client program and the postgres server are on the same host, client connects to 127.0.0.1. In the meantime, my original program blocks (not my example but very probably the reasons are the same). I typed "ps -C testprogramname -o wchan:80=" and the output was only a single dash ( "-" ). I searched for the complete stack in /proc/$pid/stack (where $pid) was the pid of my process but this file doesn't exists !! Why ? I'm waiting for my example to block in order to send you what you request me about the test program (even if the output almost surely will be the same). Regards, Andrea Grassi -Messaggio originale- Da: Craig Ringer [mailto:ring...@ringerc.id.au] Inviato: venerdì 16 dicembre 2011 9.24 A: andreagra...@sogeasoft.com Cc: pgsql-bugs@postgresql.org Oggetto: Re: [BUGS] BUG #6342: libpq blocks forever in "poll" function On 12/16/2011 03:45 PM, andreagra...@sogeasoft.com wrote: > The following bug has been logged on the website: > > Bug reference: 6342 > Logged by: Andrea Grassi > Email address: andreagra...@sogeasoft.com > PostgreSQL version: 8.4.8 > Operating system: SUSE SLES 10 SP4 64 BIT > Description: > > Hi, > I have a big and strange problem. Sometimes, libpq remains blocked in “poll” > function even if the server has already answered to the query. If I attach > to the process using kdbg I found this stack: > > __kernel_vsyscall() > poll() from /lib/libc.so.6 Given all you described (thanks for all the detail!) then if client and server are on different hosts this could easily be a NIC driver or HW issue. It'd be interesting to see the output of: ps -C testprogramname -o wchan:80= -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
1. Yes, obviously I launched that command when the program was blocked. 2. The system release is "SUSE SLES 10 SP4 64 BIT" with kernel 2.6.16.60. Maybe it's not the last release but it can justify the blocks ? In other systems (VMWARE) the same system work fine. What you suspect ? libpq ? linux release ? hardware ? If you need other informations let me know. Regards, Andrea -Messaggio originale- Da: Craig Ringer [mailto:ring...@ringerc.id.au] Inviato: sabato 17 dicembre 2011 7.19 A: Andrea Grassi Cc: pgsql-bugs@postgresql.org Oggetto: Re: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function On 16/12/2011 10:10 PM, Andrea Grassi wrote: > The client program and the postgres server are on the same host, client > connects to 127.0.0.1. > In the meantime, my original program blocks (not my example but very probably > the reasons are the same). > > I typed "ps -C testprogramname -o wchan:80=" and the output was only a single > dash ( "-" ). That means it's not waiting in a kernel call right now. Was the program in the hung state you've observed at the time you ran the command? Its output would only be interesting when it's hung. > I searched for the complete stack in /proc/$pid/stack (where $pid) was the > pid of my process but this file doesn't exists !! Why ? Old kernel, maybe? You're running on some kind of enterprise-y distro, so who knows how ancient half the stuff in there is. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
Hi, Craig Now my process is blocked and I have the case in my hands. Do you have something to ask me in order to have more details ? Regards, Andrea -Messaggio originale- Da: Craig Ringer [mailto:ring...@ringerc.id.au] Inviato: sabato 17 dicembre 2011 7.19 A: Andrea Grassi Cc: pgsql-bugs@postgresql.org Oggetto: Re: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function On 16/12/2011 10:10 PM, Andrea Grassi wrote: > The client program and the postgres server are on the same host, client > connects to 127.0.0.1. > In the meantime, my original program blocks (not my example but very probably > the reasons are the same). > > I typed "ps -C testprogramname -o wchan:80=" and the output was only a single > dash ( "-" ). That means it's not waiting in a kernel call right now. Was the program in the hung state you've observed at the time you ran the command? Its output would only be interesting when it's hung. > I searched for the complete stack in /proc/$pid/stack (where $pid) was the > pid of my process but this file doesn't exists !! Why ? Old kernel, maybe? You're running on some kind of enterprise-y distro, so who knows how ancient half the stuff in there is. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
Sorry if I insist, but now I have the case at hand (my test program is now blocked), so I can check and verify all what you want. I would like to know if it can be a libpq bug or if you think the fault is due to a system bug or to a machine issue and in this case I would be grateful if you could give me a hint on what could be. Regards, Andrea -Messaggio originale- Da: Craig Ringer [mailto:ring...@ringerc.id.au] Inviato: sabato 17 dicembre 2011 7.19 A: Andrea Grassi Cc: pgsql-bugs@postgresql.org Oggetto: Re: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function On 16/12/2011 10:10 PM, Andrea Grassi wrote: > The client program and the postgres server are on the same host, client > connects to 127.0.0.1. > In the meantime, my original program blocks (not my example but very probably > the reasons are the same). > > I typed "ps -C testprogramname -o wchan:80=" and the output was only a single > dash ( "-" ). That means it's not waiting in a kernel call right now. Was the program in the hung state you've observed at the time you ran the command? Its output would only be interesting when it's hung. > I searched for the complete stack in /proc/$pid/stack (where $pid) was the > pid of my process but this file doesn't exists !! Why ? Old kernel, maybe? You're running on some kind of enterprise-y distro, so who knows how ancient half the stuff in there is. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
R: R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
000",
bkini = 0, bkfin = 0, stato = 85 'U',
cdpeg = '\000' ,
grpeg =
"\000\000\000\000\000\000\000\000\000\065\000\000\000\000\000\000\000\000\000",
tscon = 0 '\000', fillc = "\000\000\000", qtfan = 0,
qtpro = 0, bkpeg = 0, lnuti = 0, anpia = "\000",
nupia = "\000\000\000\000\000", nurig = "\000\000\000\000\000",
nupid = "\000\000\000\000",
fill = '\000' ,
"\bÊÜÿÏ£\005\bU\000\000\000°\000\071\brÉÜÿph\021\t\034Ý2\b\000\000\000\000¸ÉÜÿ\215×,÷\220ÉPEZZI",
'\000' }
#25 0x08056f93 in cal_net () at /home/uwrk/pgsai/WRKUNX/g_mrprun.c:340
lotlt = 0
qta_app = 2.1220281700514382e-314
qta_incr = 8.2383361536408976e-315
n_volte = 121
it = 136
tsmax = 0
#26 0x08056f3c in mrp_run () at /home/uwrk/pgsai/WRKUNX/g_mrprun.c:317
counter = 23036
#27 0x08056cf9 in conf_dat () at /home/uwrk/pgsai/WRKUNX/g_mrprun.c:250
No locals.
#28 0x08056d56 in r_keybot (bm=36) at /home/uwrk/pgsai/WRKUNX/g_mrprun.c:265
No locals.
#29 0x08056ccb in s_entry (nsc=0x9116870 "g_mrprun.jam", con=128)
at /home/uwrk/pgsai/WRKUNX/g_mrprun.c:240
result = 137551132
stat_master = {st_dev = 651884900619439004, __pad1 = 62940,
st_ino = 1, st_mode = 4141232116, st_nlink = 24, st_uid = 1,
st_gid = 4292660168, st_rdev = 583229779520846990, __pad2 = 0,
st_size = -2307184, st_blksize = 136712600, st_blocks = 152135792,
st_atim = {tv_sec = 151778824, tv_nsec = -2307160}, st_mtim = {
tv_sec = 134928144, tv_nsec = 136512150}, st_ctim = {
tv_sec = 135726702, tv_nsec = 137550944}, __unused4 = 136712600,
__unused5 = 152135792}
stat_artico = {st_dev = 0, __pad1 = 4272, st_ino = 152140972,
st_mode = 1, st_nlink = 151778780, st_uid = 136712600,
st_gid = 4141232116, st_rdev = 128984812658, __pad2 = 12,
st_size = 0, st_blksize = -153735180, st_blocks = -2307224,
st_atim = {tv_sec = -154863084, tv_nsec = 151778768}, st_mtim = {
tv_sec = -2307184, tv_nsec = 12}, st_ctim = {tv_sec = 136250915,
tv_nsec = 40}, __unused4 = 1, __unused5 = 151778768}
stat_disbas = {st_dev = 135667194, __pad1 = 51960,
st_ino = 4292659912, st_mode = 136712600, st_nlink = 0, st_uid = 3,
st_gid = 4292659928, st_rdev = 5514874160500, __pad2 = 48,
st_size = -153730728, st_blksize = 136152200, st_blocks = 136712600,
st_atim = {tv_sec = 152153576, tv_nsec = -2307304}, st_mtim = {
tv_sec = 136147953, tv_nsec = 151914368}, st_ctim = {
tv_sec = 151916720, tv_nsec = 152151728}, __unused4 = 4140104046,
__unused5 = 0}
#30 0x08170570 in sm_call_fnc ()
No symbol table info available.
#31 0x081a7ddf in sm_fmfunc ()
No symbol table info available.
#32 0x081a7a20 in sm_frmtail ()
No symbol table info available.
#33 0x081a7772 in sm_frmfile ()
No symbol table info available.
#34 0x081a19ca in sm_r_window ()
No symbol table info available.
#35 0x081a18c8 in sm_r_there ()
No symbol table info available.
#36 0x08190cd4 in sm_jform ()
No symbol table info available.
#37 0x08190135 in sm_jexec_top ()
No symbol table info available.
#38 0x08190015 in sm_jtop ()
No symbol table info available.
#39 0x0807d11b in start_up ()
No symbol table info available.
#40 0x08056a71 in common_main (argc=2, argv=0xffdcd444)
at /home/pgsai/include/p_mainfi.h:11
No locals.
#41 0x08056998 in main (argc=2, argv=0xffdcd444)
at /home/pgsai/include/p_mainnm.h:17
No locals.
I am available for further requests.
Regards, Andrea
-Messaggio originale-
Da: Alvaro Herrera [mailto:alvhe...@commandprompt.com]
Inviato: martedì 20 dicembre 2011 16.43
A: Andrea Grassi
Cc: 'Craig Ringer'; Tom Lane; Pg Bugs
Oggetto: Re: R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
Excerpts from Andrea Grassi's message of mar dic 20 06:01:55 -0300 2011:
> Sorry if I insist, but now I have the case at hand (my test program is now
> blocked), so I can check and verify all what you want.
> I would like to know if it can be a libpq bug or if you think the fault is
> due to a system bug or to a machine issue and in this case I would be
> grateful if you could give me a hint on what could be.
Please attach GDB to the stuck process (gdb -p `pidof testprogram`) and
grab a backtrace (bt full).
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
R: R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
You wrote: > I also have a client suffering an occasional 'application hang' running Suse > 11.2 and postgressql 8.4 > on an 8 core box which is not reproducable in a VMWare test environment. > Access to postgres is libpq 127.0.0.1 as well. > Unfortunately the client must restart ASAP and I have not produced a 'test > case'. But you examined the stack ? It's similar to mine ? #0 0xe410 in __kernel_vsyscall () No symbol table info available. #1 0xf76539cb in poll () from /lib/libc.so.. #2 0xf770d39a in pqSocketCheck () from /home/pg/pgsql/lib-32/libpq.so.5 #3 0xf770d49d in pqWaitTimed () from /home/pg/pgsql/lib-32/libpq.so.5 #4 0xf770d513 in pqWait () from /home/pg/pgsql/lib-32/libpq.so.5 #5 0xf770c6d6 in PQgetResult () from /home/pg/pgsql/lib-32/libpq.so.5 #6 0xf770c89c in PQexecFinish () from /home/pg/pgsql/lib-32/libpq.so.5 Can you specify the details of hardware and platform of your machine to understand if it can have something in common with the mine and so to understand the reason/origin of the bug? Thanks. Andrea -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
R: R: R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
This is the server side stack kept by gdb: (gdb) bt full #0 0x2b6488588ae5 in recv () from /lib64/libc.so.6 No symbol table info available. #1 0x00550cd2 in secure_read () No symbol table info available. #2 0x005563a4 in pq_recvbuf () No symbol table info available. #3 0x005567a7 in pq_getbyte () No symbol table info available. #4 0x005d33e6 in PostgresMain () No symbol table info available. #5 0x005a9708 in ServerLoop () No symbol table info available. #6 0x005aa2b7 in PostmasterMain () No symbol table info available. #7 0x005580be in main () No symbol table info available. The netstat command on client and server connection has this output: The first line should be the server, the second the client. Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 127.0.0.1:5432 127.0.0.1:53129 ESTABLISHED - tcp 48 0 127.0.0.1:53129 127.0.0.1:5432 ESTABLISHED 29802/g_mrprun.e Regards, Andrea -Messaggio originale- Da: Tom Lane [mailto:t...@sss.pgh.pa.us] Inviato: martedì 20 dicembre 2011 17.38 A: Andrea Grassi Cc: harry...@comcast.net; 'Craig Ringer'; 'Pg Bugs'; 'Alvaro Herrera' Oggetto: Re: R: R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function "Andrea Grassi" writes: > #0 0xe410 in __kernel_vsyscall () > No symbol table info available. > #1 0xf76539cb in poll () from /lib/libc.so.. > #2 0xf770d39a in pqSocketCheck () from /home/pg/pgsql/lib-32/libpq.so.5 > #3 0xf770d49d in pqWaitTimed () from /home/pg/pgsql/lib-32/libpq.so.5 > #4 0xf770d513 in pqWait () from /home/pg/pgsql/lib-32/libpq.so.5 > #5 0xf770c6d6 in PQgetResult () from /home/pg/pgsql/lib-32/libpq.so.5 > #6 0xf770c89c in PQexecFinish () from /home/pg/pgsql/lib-32/libpq.so.5 What about a stack trace from the connected server process? libpq clearly thinks it's waiting for a message from the server, but I wonder what the server thinks. Also, what connection status does netstat show on each side? 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
R: R: R: R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
Then I meet my colleague who is the systems engineer that takes care of the machine and I explain your hints (suggested by Craig Ringer) about how detect and log kernel issues. If it can be useful, the content of file /proc/$pid/wchan in the moment of block is "_stext". In the meantime, to be sure that it could not been a libpq bug, I ask you one thing. In internet I searched for detailed specifications of poll/select system functions but I didn't understand one thing, that is which one of the 2 statement is true: 1) poll/select wait only for FUTURE modifications of ready-read state of sockets 2) poll/select check if there is something to read at the moment of the call and otherwise wait for FUTURE modifications of ready-read state Because if it was true the first statement, it could be that the answer of the server arrives between the request and the call of poll (this time is surely very short but however strictly greater than 0 and in this interval the server answer could arrive). Theoretical sequence: 1) Client request to server 2) Server answer to client 3) client wait calling poll In this case client and server go in a sort of deadlock because server and client wait each other for the other and could be a libpq bug. What do you think about ? This scenario could be possible or the true statement is the second ? Regard, Andrea -Messaggio originale- Da: Craig Ringer [mailto:ring...@ringerc.id.au] Inviato: mercoledì 21 dicembre 2011 0.56 A: Tom Lane Cc: Andrea Grassi; harry...@comcast.net; 'Pg Bugs'; 'Alvaro Herrera' Oggetto: Re: R: R: R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function On 21/12/2011 1:42 AM, Tom Lane wrote: > Hrm. What's with the 48 bytes in the client's receive queue? Surely > the kernel should be reporting that the socket is read-ready, if it's > got some data. I think you've found an obscure kernel bug somehow > it's failing to wake the poll() caller. > I've been leaning that way too; that's why I was asking him for /proc/$pid/stack and `wchan -C programname -o wchan:80=` output - to get some idea of what function in the kernel it's sitting in. Unfortunately the OP is on some enterprise distro that doesn't have /proc/$pid/stack . wchan info would still be useful. I wonder how old their kernel is? The bug could've already been fixed. /proc/pid/stack has been around since 2008 so it must be pretty elderly. OP: You can also get a kernel stack for a process by enabling the magic SysRQ key (see Google) then using Alt-SysRq-T . This requires a physical keyboard directly connected to the server. It emits the stack information via dmesg. See: http://en.wikipedia.org/wiki/Magic_SysRq_key There's a "sysrqd" that apparently lets you use these features remotely, but I've never tried it. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
R: R: R: R: R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function
To try to solve this problem my colleague (the systems engineer that takes care of the machine) did: 1. Disable drivers HP : NOT SOLVED 2. Disable Hyperthreading: NOT SOLVED 3. Reduced the phisical CPU (enabled on boot) from 32 to 16: THIS SOLVED THE PROBLEM. Now 2 weeks passed without blocking and the problem seems temporary solved. We have made an accurate test on the hardware but it's seems to be ok. It's seems to be a kernel bug, so I posted the problem to Novell support. Thanks for the help. Regards Andrea Grassi -Messaggio originale- Da: Tom Lane [mailto:t...@sss.pgh.pa.us] Inviato: mercoledì 21 dicembre 2011 17.01 A: Andrea Grassi Cc: 'Craig Ringer'; harry...@comcast.net; 'Pg Bugs'; 'Alvaro Herrera' Oggetto: Re: R: R: R: R: R: [BUGS] BUG #6342: libpq blocks forever in "poll" function "Andrea Grassi" writes: > In internet I searched for detailed specifications of poll/select system > functions but I didn't understand one thing, that is which one of the 2 > statement is true: > 1) poll/select wait only for FUTURE modifications of ready-read state of > sockets > 2) poll/select check if there is something to read at the moment of the call > and otherwise wait for FUTURE modifications of ready-read state #1 is nonsense. If poll worked like that, it would be impossible for anyone to use it without suffering from race conditions. But if you don't see where exactly the poll() specification says so, I observe that it says first that poll sets the bit(s) if the requested condition is true, and second that *if* none of the events have occurred yet, poll should wait. See for instance http://pubs.opengroup.org/onlinepubs/007908799/xsh/poll.html 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 #2700: tsearch2: snowball api outdated.
The following bug has been logged online: Bug reference: 2700 Logged by: Andrea C. Granata Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2beta1 Operating system: Linux Description:tsearch2: snowball api outdated. Details: Hi, Please update snowball api (api.c, api.h, utilities.c, header.h in contrib/tsearch/snowball) otherwise gendict doesn't work. Bye, Andrea. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] Postgres 9.0 crash on win7
ll ModLoad: `7004 `700ad000 C:\Program Files (x86)\PostgreSQL\9.0\bin\libgeos_c-1.dll ModLoad: `6828 `68422000 C:\Program Files (x86)\PostgreSQL\9.0\bin\libgeos-3-2-2.dll ModLoad: `70f4 `71055000 C:\Program Files (x86)\PostgreSQL\9.0\bin\libxml2-2.dll ModLoad: `0109 `010c9000 C:\Program Files (x86)\PostgreSQL\9.0\bin\libproj.dll ntdll!NtTerminateProcess+0xa: `7799017a c3 ret 0:000> ~*k . 0 Id: ec0.66c Suspend: 0 Teb: `7efdb000 Unfrozen Child-SP RetAddr Call Site `0013ddc8 `73dd601a ntdll!NtTerminateProcess+0xa `0013ddd0 `73dccf87 wow64!whNtTerminateProcess+0x46 `0013de00 `73d5276d wow64!Wow64SystemServiceEx+0xd7 `0013e6c0 `73dcd07e wow64cpu!TurboDispatchJumpAddressEnd+0x24 `0013e780 `73dcc549 wow64!RunCpuSimulation+0xa `0013e7d0 `779884c8 wow64!Wow64LdrpInitialize+0x429 `0013ed20 `77987623 ntdll!LdrpInitializeProcess+0x17e2 `0013f220 `7797308e ntdll! ?? ::FNODOBFM::`string'+0x2bea0 `0013f290 ` ntdll!LdrInitializeThunk+0xe I hope to have executed exactly as needed the instruction of http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows#Remote_debugging_with_windbg.exe Regards, Andrea Peri. -- 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] Postgres 9.0 crash on win7
Hi, I have some update on the crash of pg9.0. seem that PG9 will crash even on windows 32bit. But meanwhile in win7-64 bit crash always at first try, in win7 32bit it crash from first and second time after restart. As report here from Postgis Team. http://postgis.refractions.net/pipermail/postgis-users/2010-October/027843.html Regards, Andrea. -- 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] Postgres 9.0 crash on win7
Hi, I have do some other test. I set autovacuum = off. With this setting the server don't crash. But certainly something go bad. Infact if (after run the query) I connect with posql as user 'postgres' and try a single command VACUUM; nothing happened. But if I try a single command ANALYZE; the server crash istantly. After this I restart the server and re-try reconnecting to PG9 but without re-run the query script. again if a run ANALYZE the server crash. I think the script has insert write something wrong in a table and after this insert. Always time someone (autovacuum or user) try an analyze this cause the crash. however seem to be the analyze to do the crash, not the vacuum. Perhaps to problem is in the INSERT INTO. that put sometime that the old PG8.4.4 can understand and use, meanwhile PG) don't understand or is not capable to use. for example, I use often some field of big size: VARCHAR(20) the next try I do is to remove the postgis components to see if again this happened. Andrea. Il 04/10/2010 04:56, Tom Lane ha scritto: Craig Ringer writes: While it's consistently crashing my Pg 9 on win7 32-bit, too, I haven't been able to get a backtrace yet. I thought it'd be trivial given the ease of reproducing the crash - but the process that's crashing isn't the backend running the query. It looks like it's one of the helpers like the stats collector, autovac, bgwriter, etc. I'm unsure which yet. I'd bet on autovacuum. You might be able to reproduce the crash in the foreground process by issuing a manual VACUUM or ANALYZE. 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
Re: [BUGS] Postgres 9.0 crash on win7
Hmm. That is suspiciously close to the location of some last-minute changes in Postgres 9.0. I wonder whether Andrea is using a version of PostGIS that was compiled against pre-9.0RC1 Postgres sources. If so, I am to and it's the latest PostGIS binary from their website. Hi, Yes, I will use the latest postgis binary released from postgis team after the release of PG9.0 stable. However seem the problem was really due to an pre-9.0RC1 postgres source. ( http://trac.osgeo.org/postgis/ticket/619#comment:3 ) I confirm that using this new version of "postgis-1.5.dll" the crash was disappeared. I think the bug is resolved. Thx for great support. Andrea Peri. -- 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 #6120: Problem running post-install step in Mac OS X Lion (GM)
The following bug has been logged online: Bug reference: 6120 Logged by: Paula Andrea Carvajal Email address: paanc...@gmail.com PostgreSQL version: 9.0.4 Operating system: Mac OS X 10.7 (GM) Description:Problem running post-install step in Mac OS X Lion (GM) Details: Problem using EnterpriseDB Mac OS X Installer version Version 9.0.4-1 (from http://www.enterprisedb.com/products-services-training/pgdownload). Error message: Problem running post-install step. Installation may not complete correctly La inicialización del clúster de la base de datos falló. MacBook 13-inch, Aluminum, Late 2008 Procesador 2 GHz Intel Core 2 Duo Memoria 8 GB 1333 MHz DDR3 Pantalla Color LCD integrada 13 pulgada(s) (1280 x 800) Gráficos NVIDIA GeForce 9400M 256 MB Software Mac OS X Lion 10.7 (11A511) -- 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 with inheritance?
POSTGRESQL BUG REPORT TEMPLATE
Your name : Andrea Girotto
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : AMD K6 450MHz
Operating System (example: Linux 2.0.26 ELF) : RedHat 6.0 (krnl 2.2.14)
PostgreSQL version (example: PostgreSQL-6.4.2) : PostgreSQL-6.4.2
Compiler used (example: gcc 2.8.0) :postgresql-6.4.2-3.i386.rpm
Please enter a FULL description of your problem:
I think that DELETE (and UPDATE) with inheritance fails (example
follows).
DELETE * FROM tablea*;
ERROR: parser: parse error at or near "*"
UPDATE tablea* SET a_field='How do you do' WHERE a_field='Hello';
ERROR: parser: parse error at or near "*"
The Tutorial says:
Many of the commands that we have already discussed (select, update
and delete) support this "*" notation, as do others, like alter.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
CREATE TABLE tablea (
a_field TEXT
);
CREATE TABLE tableb (
b_field TEXT
) INHERITS (tablea); -- inheritance!
INSERT INTO tablea (a_field) VALUES ('Hello');
INSERT INTO tableb (a_field, b_field) VALUES ('Hi', 'world');
SELECT * FROM tablea*; -- everything's OK
DELETE FROM tablea*;
UPDATE tablea* SET a_field='How do you do' WHERE a_field='Hello';
If you know how this problem might be fixed, list the solution below:
-
It seems a parser's problem.
