Re: [BUGS] BUG #5230: Limit operator slows down
On Thu, Dec 3, 2009 at 10:45 AM, aftab khan akha...@hotmail.co.uk wrote: This is not exactly the same what I posted yesterday, What I have posted today also include EXPLAIN ANALYZE OUTPUT . [ adding the list back to the CC line ] It looks like you have a problem very similar to one Laurence Laborde was complaining about recently on pgsql-performance. My discussion of the problem is here: http://archives.postgresql.org/pgsql-performance/2009-12/msg00022.php In your case, the reason why the estimates are off is because of the lack of multi-column statistics, rather than because of the choice of operator, but the issues are similar. ...Robert -- 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 #5233: delete wrong doing with subquery where condition
On Thu, Dec 3, 2009 at 8:21 PM, Fred Wei w...@niwa.co.nz wrote: The following bug has been logged online: Bug reference: 5233 Logged by: Fred Wei Email address: w...@niwa.co.nz PostgreSQL version: 8.1.11 Operating system: SUSE Linux Enterprise Server 10 SP2 (x86_64) Description: delete wrong doing with subquery where condition Details: the following steps show a scenario where delete command removes all records which are not supposed to do with a subquery condition: cod_old=# create table tmp(k int); CREATE TABLE cod_old=# insert into tmp values(1); INSERT 0 1 cod_old=# create table tmp2(k2 int); CREATE TABLE cod_old=# insert into tmp2 values(2); INSERT 0 1 cod_old=# select count(*) from tmp; count --- 1 (1 row) cod_old=# delete from tmp where k in (select k from tmp2); DELETE 1 --this is wrong, because k does not exist in tmp2! cod_old=# select count(*) from tmp; count --- 0 (1 row) cod_old=# insert into tmp values(1); INSERT 0 1 cod_old=# delete from tmp where k in (select tmp2.k from tmp2); ERROR: column t.k does not exist --the last line should be the correct behaviour. In the first query, k refers to tmp.k. This is fairly surprising in this particular case, but it's intentional. I've found that it's a good idea to almost-always qualify variable references in queries that mention more than one table. There are all kinds of confusing things that can happen if you don't. ...Robert -- 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 #5217: (new) error with VB 6.0 SP 6 and psqlODBC 8.4.1
On Fri, Nov 27, 2009 at 8:09 AM, Martin searepo...@aol.at wrote: The following bug has been logged online: Bug reference: 5217 Logged by: Martin Email address: searepo...@aol.at PostgreSQL version: 8.4.1 Operating system: M$ Vista (but does not matter) same on XP, ... Description: (new) error with VB 6.0 SP 6 and psqlODBC 8.4.1 Details: works fine with psqlODBC 8.3.4, error with psqlODBC 8.4.1 Sp.CursorType = adOpenDynamic Sp.Open SELECT field1, False :: boolean as Field2 from test LIMIT 1;, PGSQL_Connection Sp!Field2 = 1 ' error I can send mylog_3804.log and psqlodbc_3804.log, if someone is interested. Since there has been no response here, I would try reposting this problem report on pgsql-odbc. This list is technically for PostgreSQL bugs proper, and it seems that the pgsql-odbc folks don't follow it closely. ...Robert -- 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 #5226: Limit operator slows down
On Wed, Dec 2, 2009 at 11:42 AM, Craig Ringer cr...@postnewspapers.com.au wrote: On 2/12/2009 10:35 PM, aftab wrote: The following bug has been logged online: Bug reference: 5226 Logged by: aftab Email address: akha...@hotmail.co.uk PostgreSQL version: 8.3.8 Operating system: Centos 5 Description: Limit operator slows down Details: S1=SELECT * FROM position WHERE position.POSITION_STATE_ID=2 AND position.TARGET_ID=18 ORDER BY position.ID DESC ; S2=SELECT * FROM position WHERE position.POSITION_STATE_ID=2 AND position.TARGET_ID=18 ORDER BY position.ID DESC LIMIT 1 ; S1 takes 0.16ms compared to S2 which takes 5 secs. Both S1 and S2 are same except LIMIT 1 is added to S2. Please read this: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems then re-post your question to the pgsql-general mailing list, including appropriate EXPLAIN ANALYZE output for both queries, etc. Or pgsql-performance. ...Robert -- 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 #5215: Error in PgAdmin
On Thu, Nov 26, 2009 at 5:41 AM, Walter Willmertinger will...@gmail.com wrote: The following bug has been logged online: Bug reference: 5215 Logged by: Walter Willmertinger Email address: will...@gmail.com PostgreSQL version: 8.4.1 Operating system: Windows XP Prof. Description: Error in PgAdmin Details: Since we introduced 8.4.1, we had some failures of our database. The server remained the same, the application is the same as with our previous 8.3.x installation. Error 1: Missing ... pg_catalog pg_dump not possible Fixed by COPY table to FILE ... for each separate table reinstalling postgres, then restored a previous dump and run the output of the COPY I'm not sure I understand which of the above lines were part of an error message (and if so, what exactly you did that precipitated the error) and which of them are your commentary. ...Robert -- 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 #5218: Easy strategic feature requests
On Sat, Nov 28, 2009 at 5:34 PM, Russell Wallace
russell.wall...@gmail.com wrote:
The following bug has been logged online:
Bug reference: 5218
Logged by: Russell Wallace
Email address: russell.wall...@gmail.com
PostgreSQL version: 8.4.1
Operating system: Windows
Description: Easy strategic feature requests
Details:
(There wasn't a separate form for feature requests, so I'm assuming that
like most projects, this one files them together with bugs, please let me
know if that is not the case.)
Can you make Show Databases, Show Tables and Describe (table) work the way
they do in MySQL? This would make things easier for newbies and would also
make it easier to port code from MySQL; they would only need to be syntax
sugar for the corresponding information schema queries, so it would probably
only take a few lines of code, and would improve PostgreSQL's competitive
position versus MySQL out of all proportion to the apparent significance of
these features.
It would be nice if Use (database) could also be made to work, but I'm
guessing this would not be just a few lines of code. What would be easy and
still useful, however, would be if it could return a specific error message:
you can't do this in Postgres, you always need to supply a database name on
connection; again that would make life easier for newbies, and that matters
a lot for competitive advantage.
Features requests are usually discussed on pgsql-hackers. I'm not
sure there will be much support for this proposal, although I it did
take me a while to figure out the PostgreSQL equivalents of those
commands when I made the switch. For interactive use, the psql
backslash-commands are fine, but for scripted access to the schema,
the MySQL way is definitely easier. One of the problems is that
show is already a PostgreSQL verb with an incompatible meaning.
Rather than trying to be compatible with MySQL directly, I think we
might be better off adding a chapter to our documentation explaining
to ex-MySQL users how to accomplish the same things in PostgreSQL. We
might even think about adding a contrib module with user-defined
functions like show_databases(), show_tables(), describe(text), so
that someone could do SELECT describe('foo'); and get a familiar sort
of output.
...Robert
--
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 #5218: Easy strategic feature requests
On Mon, Nov 30, 2009 at 12:28 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Rather than trying to be compatible with MySQL directly, I think we
might be better off adding a chapter to our documentation explaining
to ex-MySQL users how to accomplish the same things in PostgreSQL. We
might even think about adding a contrib module with user-defined
functions like show_databases(), show_tables(), describe(text), so
that someone could do SELECT describe('foo'); and get a familiar sort
of output.
I thing so ex-MySQL needs exact DESCRIBE, exact SHOW statement. It is
some, what they used long time and then they missing it.
Well, if people aren't willing to make ANY changes to their code or
habits when porting to a new database, they're likely hosed no matter
what we do about this particular issue. That having been said, I
wouldn't personally strongly object to implementing these commands as
a convenience for MySQL users, but I suspect others will consider them
unnecessary warts, which in some sense they are.
Hypothetically we could have a super hook on server side - or hook
on psql and we can implement these statements in some contrib module.
With all respect, I think this is quite similar to several things
you've proposed previously that have been rejected. At least, I
believe it suffers from many of the same problems.
...Robert
--
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 #5218: Easy strategic feature requests
On Mon, Nov 30, 2009 at 1:42 PM, Pavel Stehule pavel.steh...@gmail.com wrote: 2009/11/30 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: I thing so ex-MySQL needs exact DESCRIBE, exact SHOW statement. It is some, what they used long time and then they missing it. You know, if they're not willing to make any adaptations, they're never really going to make the transition anyhow. If we provide bug-compatible versions of SHOW or whatever, people like that will just move on to complaining about some other difference. I'm in favor of trying to develop some documentation aimed at helping new MySQL converts, but I don't think there's much to be gained by doing more than that. +1 Any official place has sense - minimally for people who can read documentation. This seems to be the exact opposite of what you said an hour and a half ago, but, hey, at least we're all more or less in agreement now. There remains the issue of finding a qualified person who is willing to spend the time to write this documentation... ...Robert -- 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] psql -1 -f - busted
On Fri, Nov 27, 2009 at 1:42 AM, Peter Eisentraut pete...@gmx.net wrote: On tor, 2009-11-26 at 22:59 -0500, Robert Haas wrote: ISTM that if you run psql with -f -, you shouldn't expect to get an interactive shell. Rather, you should expect psql to do whatever it normally does when given -f somefilename, except using stdin rather than the file. After all, you could have left out -f altogether if you'd wanted the interactive behavior. But then IJWH. But by that logic, psql file should also set interactive mode. Those two cases are not symmetrical. If you're reading from something other than a terminal, you certainly don't want interactive mode. If you ARE reading from a terminal, you might nevertheless want non-interactive mode. And you CERTAINLY might want -1 when reading a pipe, as when you do this: ssh otherhost pg_dump | psql -1 -f - Currently, this silently fails to deliver the expected behavior. ...Robert -- 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 #5207: unable to start postgresql server services
On Fri, Nov 27, 2009 at 3:42 AM, Denny Saviant Mohammad konohabluefl...@gmail.com wrote: Well, i changed nothing in my postgresql.conf before the accident. Well, someone or something did, because stdmsg isn't ever a legal value, and it didn't put itself into that file. . But, after i try changing value on log_destination from 'stdmsg' into 'csvlog', i got this 2009-11-26 16:07:57 ICTPANIC: could not open control file global/pg_control: Permission denied This would seem to indicate that either the permissions on the PostgreSQL data directory have been changed, or you're trying to start PostgreSQL under the wrong user account. I changed it into 'syslog', i got this FATAL: invalid value for parameter log_destination: syslog I changed it again into 'eventlog', i got this 2009-11-27 15:28:03 ICTPANIC: could not open control file global/pg_control: Permission denied again.. i also try to change pg_log folder permissions, but nothing happens.. I would suggest that you post to a different mailing list, such as pgsql-novice or pgsql-general. This mailing list is for bug reports, and it doesn't sound to me like there's a bug here. I would start by setting log_destination = eventlog - since stdmsg is definitely not going to work - and then ask for help on one of those mailing lists fixing your permissions problem. ...Robert -- 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] psql -1 -f - busted
On Thu, Oct 22, 2009 at 2:42 PM, Stephen Frost sfr...@snowman.net wrote: -1 appears to be ignored when '-f -' is set. I've been bitten by this, too. It appears that -f - is in general equivalent to not specifying -f at all. In startup.c we have a test for: options.action == ACT_FILE strcmp(options.action_string, -) != 0 I suppose we could change it to: options.action == ACT_FILE (strcmp(options.action_string, -) != 0 || pset.notty) But I sort of think it should just be: options.action == ACT_FILE ISTM that if you run psql with -f -, you shouldn't expect to get an interactive shell. Rather, you should expect psql to do whatever it normally does when given -f somefilename, except using stdin rather than the file. After all, you could have left out -f altogether if you'd wanted the interactive behavior. But then IJWH. ...Robert -- 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 #5207: unable to start postgresql server services
On Sat, Nov 21, 2009 at 9:13 AM, denny saviant konohabluefl...@gmail.com wrote: The following bug has been logged online: Bug reference: 5207 Logged by: denny saviant Email address: konohabluefl...@gmail.com PostgreSQL version: 8.4.1 Operating system: windows xp pro sp3 Description: unable to start postgresql server services Details: I installed my postgresql 8.4.1 successfully without any problems. But there was a problem,the server service won't run. After spending hours of searching i postgre mailing list. I able to solve it by following the instruction in http://archives.postgresql.org/pgsql-admin/2006-05/msg00168.php . which is by assigning Log on as local system account in services properties. And voila, it works.. couple days later, this kind of trouble come again exactly after i restart w3svc service and restart my PC. (i know it after checking the log). And here's the windows event log that shows the failure.. Waiting for server startup... LOG: unrecognized log_destination key word: stdmsg FATAL: invalid value for parameter log_destination: stdmsg Is there anyone know how to solve this? I am currently using this postgresql server as my dbms of choice to finish my minor project assignment in college. Sounds like you have a bad setting for log_destination in your postgresql.conf file. ...Robert -- 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 #5211: invalid password
On Tue, Nov 24, 2009 at 6:04 AM, lee brown lee_bro...@msn.com wrote: The following bug has been logged online: Bug reference: 5211 Logged by: lee brown Email address: lee_bro...@msn.com PostgreSQL version: 8.3 Operating system: vista Description: invalid password Details: i accidentally let computer generate password atinitialize database clusterstage of installation.is there any way of undoing this error? This is not a bug. For usage questions, please try pgsql-general or pgsql-novice. That having been said, you can just change your password. If you are locked out of the database, you can get back in by changing your authentication method to trust in pg_hba.conf. http://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html ...Robert -- 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 #5210: error in intidb process when installing on japanese
On Mon, Nov 23, 2009 at 4:21 AM, Maithili maithili.manur...@gmail.com wrote: The following bug has been logged online: Bug reference: 5210 Logged by: Maithili Email address: maithili.manur...@gmail.com PostgreSQL version: 8.2 Operating system: Windows 2003 Description: error in intidb process when installing on japanese Details: i try installing postgressql 8.2 on a japanese machine which is on japanese domain. The machine name as well as the domain name is japanese. the initdb process fails to initiate giving an error unknown hostname or incorrect password. I have checked the creation of user postgres, it has the required permissions. what can be the problem. I think you're going to need to provide the actual output and/or error messages for anyone to be able to help you with this... ...Robert -- 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 #5206: wal_sync_method in stock postgresql.conf may be wrong
On Fri, Nov 20, 2009 at 6:56 PM, Alvaro Herrera alvhe...@postgresql.org wrote: The following bug has been logged online: Bug reference: 5206 Logged by: Alvaro Herrera Email address: alvhe...@postgresql.org PostgreSQL version: any Operating system: any Description: wal_sync_method in stock postgresql.conf may be wrong Details: Jaime Casanova just made me note that though most commented variables in postgresql.conf list the value that they have because of being the default, this is not the case with wal_sync_method -- it instead says fsync and then explains in a comment that the real value is something else. Now I understand why this is (it's because of the fact that the default value is platform-dependent), but it still is a bit unfortunate and it would be better to avoid it. I have two suggestions to fix this: 1. avoid displaying any value at all as if it were the true default (this would perhaps make the line invalid were the user to uncomment it) 2. change initdb so that it modifies that line too (along with shared_buffers etc) to put the actual default value in there, but without uncommenting it. I also have one non-suggestion: 3. do nothing Thoughts? I like #3 or #1 better than #2. Putting logic into initdb to edit the comments in the file doesn't really seem like a worthwhile use of time. (I still think we should get rid of the commented-out settings altogether, but that's another argument...) ...Robert -- 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 #5203: Rule affecting more than one row is only fired once, when there is no reference to the row.
On Fri, Nov 20, 2009 at 10:11 AM, Marcel Wieland
marcel.wiel...@fondsnet.de wrote:
The following bug has been logged online:
Bug reference: 5203
Logged by: Marcel Wieland
Email address: marcel.wiel...@fondsnet.de
PostgreSQL version: 8.2
Operating system: Linux
Description: Rule affecting more than one row is only fired once,
when there is no reference to the row.
Details:
BEGIN;
-- Create testing Tables
CREATE TABLE footable (
name char
);
CREATE TABLE bartable (
foo char
);
-- Insert testing Values
INSERT INTO footable (name) VALUES('a'), ('b');
-- RULE without row-reference
CREATE OR REPLACE RULE foorule AS ON UPDATE TO footable DO
INSERT INTO bartable (foo) SELECT * FROM (SELECT 'a' UNION SELECT 'b')
AS x;
-- Query fires Rule
UPDATE footable SET name = name;
-- Result
SELECT * FROM bartable;
-- Reset
DELETE FROM bartable;
-- RULE with row-reference
CREATE OR REPLACE RULE foorule AS ON UPDATE TO footable DO
INSERT INTO bartable (foo) SELECT * FROM (SELECT 'a' UNION SELECT 'b')
AS x WHERE old.name = old.name;
-- Query fires Rule
UPDATE footable SET name = name;
-- Result
SELECT * FROM bartable;
-- Cleanup
DROP TABLE footable;
DROP TABLE bartable;
ROLLBACK;
You haven't really said what the actual behavior is and what behavior
you expected, so it's a bit difficult to judge whether the behavior is
wrong, or whether your expectations are wrong. However, based on the
subject line, I'm guessing that you may be misunderstanding how rules
work. Rules operate on a query level, not on a tuple level. If you
add a DO ALSO rule, you're just constructing a new query which gets
executed in addition to the original query. If you want something
that gets fired for every tuple, you probably want a trigger.
In my experience, triggers are always better than rules for solving
all real-world problems.
...Robert
--
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 #5202: Rule affecting more than one row is only fired once with LIMIT 1
On Fri, Nov 20, 2009 at 9:58 AM, Marcel Wieland
marcel.wiel...@fondsnet.de wrote:
The following bug has been logged online:
Bug reference: 5202
Logged by: Marcel Wieland
Email address: marcel.wiel...@fondsnet.de
PostgreSQL version: 8.2
Operating system: Linux
Description: Rule affecting more than one row is only fired once with
LIMIT 1
Details:
BEGIN;
-- Create testing Tables
CREATE TABLE footable (
name char
);
CREATE TABLE bartable (
foo char
);
-- Insert testing Values
INSERT INTO footable (name) VALUES('a'), ('b');
-- RULE with LIMIT 1
CREATE OR REPLACE RULE foorule AS ON UPDATE TO footable DO
INSERT INTO bartable (foo) SELECT name FROM footable WHERE name =
old.name LIMIT 1;
-- Query fires Rule
UPDATE footable SET name = name;
-- Result
SELECT * FROM bartable;
-- Reset
DELETE FROM bartable;
-- RULE without LIMIT 1
CREATE OR REPLACE RULE foorule AS ON UPDATE TO footable DO
INSERT INTO bartable (foo) SELECT name FROM footable WHERE name =
old.name;
-- Query fires Rule
UPDATE footable SET name = name;
-- Result
SELECT * FROM bartable;
-- Cleanup
DROP TABLE footable;
DROP TABLE bartable;
ROLLBACK;
See my response to your other bug report - same issues apply here.
...Robert
--
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 #5205: Cannot ADD CONSTRAINT ... FOREIGN KEY...
On Fri, Nov 20, 2009 at 6:44 PM, Alain Baeckeroot alain.baecker...@laposte.net wrote: The following bug has been logged online: Bug reference: 5205 Logged by: Alain Baeckeroot Email address: alain.baecker...@laposte.net PostgreSQL version: 8.4.1 Operating system: Linux (Ubuntu 9.10) Description: Cannot ADD CONSTRAINT ... FOREIGN KEY... Details: I think i could add this constraint on an existing table: = select id from asset except (select asset.id from asset, base where asset.id_base = base.id); id (0 rows) = ALTER TABLE ONLY asset ADD CONSTRAINT asset_id_base_fkey FOREIGN KEY (id_base) REFERENCES base(id); ERREUR: une instruction insert ou update sur la table « asset » viole la contrainte de clé étrangère « asset_id_base_fkey » DETAIL: La clé (id_base)=(196) n'est pas présente dans la table « base ». = select * from base where id = 196; id | date_crea | date_modif | auth_crea | auth_modif | ordre -+++---+ +--- 196 | 2009-03-16 11:57:44.391607 | 2009-03-16 11:57:44.391607 | sql | sql | 7 (1 row) What is wrong ? The table asset inherits from base, but it seems to be allowed and to work (at least on the dumb test i did) I am guessing that the row may be in an inherited child of base rather than in base itself? ...Robert -- 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 #5197: JDBC: selecting oid results in Exception
On Wed, Nov 18, 2009 at 11:26 PM, Joseph Shraibman j...@selectacast.net wrote: The following bug has been logged online: Bug reference: 5197 Logged by: Joseph Shraibman Email address: ...@selectacast.net PostgreSQL version: 8.2.14 Operating system: Linux Description: JDBC: selecting oid results in Exception Details: query: select oid FROM pg_catalog.pg_class c; --- org.postgresql.util.PSQLException: Bad value for type int : 2148618421 at org.postgresql.jdbc2.AbstractJdbc2ResultSet.toInt(AbstractJdbc2ResultSet.jav a:2630) at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getInt(AbstractJdbc2ResultSet.ja va:1968) at org.postgresql.jdbc2.AbstractJdbc2ResultSet.internalGetObject(AbstractJdbc2R esultSet.java:119) at org.postgresql.jdbc3.AbstractJdbc3ResultSet.internalGetObject(AbstractJdbc3R esultSet.java:39) at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getObject(AbstractJdbc2ResultSet .java:2429) Casting oid to bigint doesn't result in an Exception Thanks for the report. If you don't get a response from anyone on this list, you might want to try the pgsql-jdbc list instead, as many of us here are not familiar with JDBC specifically. ...Robert -- 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 #5175: Unable to configure psqlodbc-08.04.0100
On Mon, Nov 9, 2009 at 7:21 PM, Vijaya Krishna Cherukuri krisveejay...@gmail.com wrote: The following bug has been logged online: Bug reference: 5175 Logged by: Vijaya Krishna Cherukuri Email address: krisveejay...@gmail.com PostgreSQL version: 8.3.8 Operating system: Debian Linux Description: Unable to configure psqlodbc-08.04.0100 Details: I am trying to configure psqlodbc-08.04.0100 in my debian linux. I am getting the following error: nrtrde:/home/vijay/sample/psqlodbc-08.04.0100# ./configure nrtrde:/home/vijay/sample/psqlodbc-08.04.0100# ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for pg_config... /usr/local/pgsql/include ./configure: line 2872: /usr/local/pgsql/include: is a directory ./configure: line 2873: /usr/local/pgsql/include: is a directory checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... configure: error: cannot compute suffix of object f iles: cannot compile See `config.log' for more details. Can you please help me with this as it is very urgent..? Since this is a pgsql-odbc question, you might want to ask on pgsql-odbc rather than here. But just for starters you might want to follow the directions in the error message: See `config.log' for more details. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] pgsql-jdbc/pgsql-odbc
I see that there's been no response to bugs #5194, #5187, #5051. Should we consider adding a message to the bug reporting page that suggests emailing the relevant list directly for JDBC/ODBC bugs? We seem to get a lot of those here. The other frequent one that seems to come up is the one-click installer. I think this has been discussed before but I can't now recollect whether there was any clear conclusion or what it was. I just feel bad for people who email us hoping for help and get no response at all. ...Robert -- 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 #5191: now() returns same value from Perl.
On Mon, Nov 16, 2009 at 12:59 PM, Clark Pearson
cloink_frigg...@ntlworld.com wrote:
The following bug has been logged online:
Bug reference: 5191
Logged by: Clark Pearson
Email address: cloink_frigg...@ntlworld.com
PostgreSQL version: 8.3.7
Operating system: Windows
Description: now() returns same value from Perl.
Details:
Hi,
I don't know if this is a core database issue, or a Perl DBD::Pg one;
however the same thing occurs using the 'pure perl' DBD::PgPP as well, so
the evidence points to the db. Note that I do not observe this behaviour if
connected via psql from a Windows DOS terminal.
If I 'SELECT now()' repeatedly from a perl script connected to the database
via DBD::Pg, the returned value does not get updated to the new system
time.
I have tried a number of different tricks, but the only way I have managed
to make it return a value not the same as the first time is by
dis-/reconnecting.
Here is a simple perl script to test with
#!perl
use strict;
use warnings;
use DBI;
my $dbh = DBI-connect( 'DBI:Pg:dbname=tc;host=localhost;port=5432',
'user', 'pass',
{ RaiseError = 1
, PrintError = 1
, AutoCommit = 0
}
);
my $qry = q(
select current_timestamp
);
$qry = $dbh-prepare($qry);
my $tmp = $dbh-selectrow_array(
'select current_timestamp');
warn $tmp;
sleep 2;
my $tm2 = $dbh-selectrow_array('SELECT 1');
warn $tm2;
my $tm3 = $dbh-selectrow_array('SELECT now()');
warn $tm3;
$dbh-disconnect();
__END__
now() doesn't advance within a transaction. If you want a value that
does, use clock_timestamp().
See
http://www.postgresql.org/docs/current/interactive/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT
...Robert
--
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 #5184: default tablespace owner is not dumped
On Fri, Nov 13, 2009 at 1:13 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: The following command does not change the output of pg_dumpall: alter tablespace pg_default owner to bob; I don't think this is a bug. It's one specific aspect of a general principle that system objects don't get dumped. If they did, using pg_dump to upgrade across major versions would be somewhere between impossible and your worst nightmare. It might be nice if manual changes to system objects got dumped, but that's really an AI-complete problem --- which properties of the objects represent manual changes, and how can we know whether trying to apply those changes to a new system version will work? Well, in this particular case, the existence of the default tablespace seems like something that should not be dumped, but all properties other than name and location - currently, owner and acl - seem like they should be dumped. If we don't, then we have the odd situation that dumping and restoring a database on THE SAME version of PostgreSQL doesn't produce an equivalent database - you may have permissions errors where you didn't before, or visca-versa. I think it would be over the top to suggest that pg_dump has to cope with modifications that can only occur through manual updates to the system catalogs, but it seems like anything that can be done using DDL statements should be handled. It seems a little wonky to admit ALTER statements against internal Pg names, I agree... I suppose we could try to define some alternate syntax. ...Robert -- 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 #5184: default tablespace owner is not dumped
On Fri, Nov 13, 2009 at 10:39 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: I think it would be over the top to suggest that pg_dump has to cope with modifications that can only occur through manual updates to the system catalogs, but it seems like anything that can be done using DDL statements should be handled. Like, say, DELETE FROM pg_proc? That's not DDL... Exactly. There's nothing we can do about random changes to system catalogs, but it seems pretty strange to allow someone to issue an ALTER TABLESPACE command but then ignore it in pg_dump. ...Robert -- 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 #5186: Not install daemon
On Fri, Nov 13, 2009 at 8:52 PM, obelich obel...@gmail.com wrote: The following bug has been logged online: Bug reference: 5186 Logged by: obelich Email address: obel...@gmail.com PostgreSQL version: 8.4.1 Operating system: Opensuse 11.2 Description: Not install daemon Details: Hi we want to report a problem in the instalation with .bin file in Opensuse 11.2 this one give send a message problem, then dont install the daemon to start PostgreSQL service, send the follow error Problem runing post-install step. installation may not complete correctly la inicializacion del cluster de la base de datos fallo The initialization for the cluster as fail Sorry my english is bad and the message up in spanish I think you might want to report this problem to OpenSuse. If there's a bug here, it sounds like a packaging problem, rather than a PostgreSQL problem. ...Robert -- 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 #5184: default tablespace owner is not dumped
The following bug has been logged online: Bug reference: 5184 Logged by: Robert Haas Email address: robertmh...@gmail.com PostgreSQL version: CVS HEAD Operating system: Linux Description:default tablespace owner is not dumped Details: The following command does not change the output of pg_dumpall: alter tablespace pg_default owner to bob; But this one does: alter tablespace foo owner to bob; The problem is that we only emit CREATE TABLESPACE commands for non-system tablespaces. That is correct, but it seems like we might need to emit ALTER TABLESPACE commands instead for system tablespaces. -- 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 #5128: Returning nested composite types in plpython
On Tue, Oct 20, 2009 at 12:19 PM, landrevi...@deadtreepages.com wrote:
The following bug has been logged online:
Bug reference: 5128
Logged by:
Email address: landrevi...@deadtreepages.com
PostgreSQL version: 8.4
Operating system: FreeBSD
Description: Returning nested composite types in plpython
Details:
I have nested custom types and when I try to return a mapping in python the
nested type gives me a malform record error. Here is my test code and the
error:
create type type1 as (
col1 text,
col2 text
);
create type type2 as (
col1 text,
col2 text,
test_type type1
);
create function returnComposite(test_one text, test_three text) RETURNS
type2 as
$$
return {'col1': test_one, 'col2': test_one, 'test_type': {'col1':
test_two,
'col2': test_two}}
$$ language plpythonu;
select returnComposite('test1','test2')
ERROR: malformed record literal: {'col2': 'test2', 'col1': 'test2'}
SQL state: 22P02
Detail: Missing left parenthesis.
If I put the nested type as ('test': test_two) it will return me the type
but it includes extra quotes. The only way to make this work is make a
select using plpy returning a type2 column.
It would seem that the nested composite type is not being processed by
plpython and going straight to the rowtypes processing.
See Peter's note here - apparently this is not supported.
http://archives.postgresql.org/pgsql-bugs/2009-11/msg00073.php
...Robert
--
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 #5171: Composite type with array does not translate in plpythonu
On Sat, Nov 7, 2009 at 5:23 AM, Peter Eisentraut pete...@gmx.net wrote: On fre, 2009-11-06 at 17:29 +, Jason wrote: When I have a plpythonu function returning a composite type that has an array column, the function does not work when I try to return a list for that column. There is a patch proposed to address that in 8.5, but before that, arrays are pretty much not supported in plpythonu. Is this at all related to bug #5128? ...Robert -- 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 #5165: Poor performance with Left-join where right side does not exist
On Wed, Nov 4, 2009 at 3:35 PM, Tom Lane t...@sss.pgh.pa.us wrote: assaf assaf_l...@yahoo.com writes: PostgreSQL version: 8.37 Description: Poor performance with Left-join where right side does not exist 8.4 might be smarter about this case for you. It's hard to tell for sure with so few details. EXPLAIN output would be a good place to start, and EXPLAIN ANALYZE for the queries that run quickly enough that you can let them run to completion. ...Robert -- 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 #5147: DBA can not access view
2009/11/2 donniehan donnie...@126.com: Hi Tom, I agree with Hxli. It may be a good way to add permissions check when create the view. I also find 2 pieces of words in the document about the owner of the object. By default, only the owner of an object can do anything with the object. as the owner has all privileges by default. In my case, as the view1 is already owned by user1, so user1 should has all privileges of view1, but user1 can not select from view1, I am very confused by these words. So it maybe necessary to check the user's permissions when he create the object. Guys, this is pretty straightforward. The permissions on the view determine who can access it. The permissions of the view owner determine what the view can access. The way to think about this may be that a view acts a bit like a setuid program under UNIX: a regular user can gain superuser privileges; a superuser can give them up. This may or may not make sense to you and it may or may not be what you want, but it's NOT A BUG. It's done that way on purpose, it's well-documented, and it's been that way for a long time. If you want some explanation of WHY is that way and what it might be useful for, start by reading the documentation and then if you have questions, ask on the appropriate mailing list, maybe pgsql-general or pgsql-novice. ...Robert -- 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 #5140: initdb crashes
On Tue, Oct 27, 2009 at 10:47 AM, Marcus Lundblad marcus.lundb...@mogul.com wrote: The following bug has been logged online: Bug reference: 5140 Logged by: Marcus Lundblad Email address: marcus.lundb...@mogul.com PostgreSQL version: 8.3.8 Operating system: Solaris 10 Description: initdb crashes Details: Hi I compiled version 8.3.8 of postgres on a Solaris 10 machine. When running initdb it crashes like this: postg...@webbkartbas02 /usr/local/postgres/bin/initdb -D /usr/local/postgres/data/ -d Running in debug mode. VERSION=8.3.8 PGDATA=/usr/local/postgres/data share_path=/usr/local/postgres/share PGPATH=/usr/local/postgres/bin POSTGRES_SUPERUSERNAME=postgres POSTGRES_BKI=/usr/local/postgres/share/postgres.bki POSTGRES_DESCR=/usr/local/postgres/share/postgres.description POSTGRES_SHDESCR=/usr/local/postgres/share/postgres.shdescription POSTGRESQL_CONF_SAMPLE=/usr/local/postgres/share/postgresql.conf.sample PG_HBA_SAMPLE=/usr/local/postgres/share/pg_hba.conf.sample PG_IDENT_SAMPLE=/usr/local/postgres/share/pg_ident.conf.sample 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 database encoding has accordingly been set to SQL_ASCII. The default text search configuration will be set to english. fixing permissions on existing directory /usr/local/postgres/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 /usr/local/postgres/data/base/1 ... DEBUG: invoking IpcMemoryCreate(size=38264832) DEBUG: creating and filling new WAL file DEBUG: done creating and filling new WAL file LOG: database system was shut down at 2009-10-27 15:26:27 CET LOG: incorrect resource manager data checksum in record at 0/20 LOG: invalid primary checkpoint record LOG: invalid secondary checkpoint link in control file PANIC: could not locate a valid checkpoint record Abort - core dumped child process exited with exit code 134 initdb: removing contents of data directory /usr/local/postgres/data The following params to ./configure was passed when compiling postgres: ./configure --prefix=/usr/local/postgres/ --with-pam --with-libedit-preferred --with-libxml --with-libxslt --with-gssapi --enable-thread-safety --enable-dtrace--with-includes=/usr/local/include:/usr/include:/usr/gcc/incl ude:/usr/sfw/include/ --with-libs=/usr/local/lib:/usr/gcc/lib:/usr/lib --with-libraries=/usr/local/lib:/usr/gcc/lib:/usr/lib the version of gcc is: sparc-sun-solaris2.10-gcc (GCC) 4.2.1 (20090222) (gccfss) Can you get a backtrace from the core dump? ...Robert -- 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 #5149: Can't untar the src code file
On Thu, Oct 29, 2009 at 6:14 PM, Don Fox donf...@mac.com wrote: The following bug has been logged online: Bug reference: 5149 Logged by: Don Fox Email address: donf...@mac.com PostgreSQL version: 8.4.1 Operating system: Mac X Snowleopard Description: Can't untar the src code file Details: tar -x post*.tar ^C c-76-123-226-197:Downloads donfox1$ tar -xvf postgresql-8.4.1.tar tar: Unrecognized archive format: Inappropriate file type or format tar: Error exit delayed from previous errors. Well, there's evidently something different between what you're doing and what everyone else in the world is doing, but I don't know what it is. You either have a messed up tarball or a broken tar. I'd start by downloading the file again and having another go at it. If that doesn't work, I'd try untarring it on a different machine. If neither of those things work and you're still having trouble, you should probably let us know the exact URL from which you downloaded the tarball so that someone else can attempt to reproduce the problem. ...Robert -- 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 #5150: math bug
On Fri, Oct 30, 2009 at 1:39 AM, Gray g...@ms-irk.ru wrote: The following bug has been logged online: Bug reference: 5150 Logged by: Gray Email address: g...@ms-irk.ru PostgreSQL version: 8.2.6 Operating system: i686-pc-linux-gnu Description: math bug Details: select 1/3*3,(1.0/3.0)*3.0,floor((1.0/3.0)*3.0); returns 0, 1, 0 Well, the first answer is correct, because 1/3 is a request for integer division, so you get 0, and 0 * 3 is still zero. I don't believe the second answer is really what you got, because surely if you requested floating-point division the answer would be a floating point number, not just 1. On pg 8.3.8, I get 0.0, which explains why the third answer comes out to zero. In general, floating point arithmetic is inaccurate and sucky. That has nothing to do with PostgreSQL; it's just life. http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems ...Robert -- 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 #5131: The pgsql will lost
On Wed, Oct 21, 2009 at 11:23 PM, aihongwei ufo008...@163.com wrote: The following bug has been logged online: Bug reference: 5131 Logged by: aihongwei Email address: ufo008...@163.com PostgreSQL version: 8.0.0 Operating system: linux x86_64 Description: The pgsql will lost Details: In x86_64 platform, I input command ulimit -s 2048 to limit the stack size.Then I startup the server,and when i do some recursion operation, the pgsql will lost in some time. It seems that The stack_max_depth does work. example: CREATE FUNCTION infinite_recurse() returns int as 'select infinite_recurse()' language sql; select infinite_recurse(); *scratches head* Well, you haven't really told us what happens when you do this. Does it hang up forever? How long did you wait? Does it crash? The default value for max_stack_depth (NOT stack_max_depth) seems to be 2MB, so setting the system limit to the same value seems like a bad idea. http://www.postgresql.org/docs/current/interactive/runtime-config-resource.html#GUC-MAX-STACK-DEPTH ...Robert -- 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 #5130: Failed to run initdb:1
On Wed, Oct 21, 2009 at 12:51 PM, flamindrag...@gmail.com wrote: The following bug has been logged online: Bug reference: 5130 Logged by: Email address: flamindrag...@gmail.com PostgreSQL version: any Operating system: Win XP Pro SP2 Description: Failed to run initdb:1 Details: here's the log of the bug The files belonging to this database system will be owned by user SYSTEM. This user must also own the server process. The database cluster will be initialized with locale Polish_Poland.1250. initdb: could not find suitable text search configuration for locale Polish_Poland.1250 The default text search configuration will be set to simple. creating directory C:/Program Files/PostgreSQL/8.3/data ... ok creating subdirectories ... ok selecting default max_connections ... Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. 10 selecting default shared_buffers/max_fsm_pages ... Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. 400kB/2 creating configuration files ... ok creating template1 database in C:/Program Files/PostgreSQL/8.3/data/base/1 ... ok initializing pg_authid ... Nie moľna odnale«† okre˜lonego pliku. child process exited with exit code 1 initdb: removing data directory C:/Program Files/PostgreSQL/8.3/data Nie moľna odnale«† okre˜lonego pliku. = unable to find the file What's interesting to me is that I can't find that string anywhere in the PostgreSQL 8.3 sources. I think this must be an operating system error message. It looks like initdb is trying to invoke the postgres executable as a standalone backend, and failing. There is some code in initdb.c's main() routine which appears to be intended to prevent this from happening, or at least throw a less cryptic error message, but it's evidently not working for you for some reason. I speculate that this might be some kind of funky permissions issue, but I am not a Windows expert... ...Robert -- 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 #5132: Invalid Function
On Thu, Oct 22, 2009 at 3:23 AM, Geok Hua Yap geokhua8...@yahoo.com.sg wrote: The following bug has been logged online: Bug reference: 5132 Logged by: Geok Hua Yap Email address: geokhua8...@yahoo.com.sg PostgreSQL version: 8.3.1 Operating system: CentOS 5.2 Description: Invalid Function Details: select timeofday()::timestamp; ERROR: invalid input syntax for type timestamp: Thu Oct 22 15:16:25.113963 2009 SGT This is not a bug. timeofday() returns text - maybe you want clock_timestamp()? http://www.postgresql.org/docs/current/interactive/functions-datetime.html ...Robert -- 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: 答复: 答复: [BUGS] Encounter shared memory e rror when running createlang command!
2009/9/29 Yaming Gu yaming...@w-oasis.com: Hi, Robert, According to your recommendations, I tried to load plperu, almost the same error messages have shown: D:\Program Files\Postgresql\8.3\bincreatelang -U postgres plperlu example Password: createlang: language installation failed: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The following is pg_log message: 2009-09-29 14:28:07 HKT LOG: loaded library $libdir/plugins/plugin_debugger.dll 2009-09-29 14:28:44 HKT LOG: loaded library $libdir/plugins/plugin_debugger.dll 2009-09-29 14:28:50 HKT LOG: loaded library $libdir/plugins/plugin_debugger.dll 2009-09-29 14:28:53 HKT LOG: loaded library $libdir/plugins/plugin_debugger.dll Substitution pattern not terminated at line 1. 2009-09-29 14:28:55 HKT LOG: Server process (PID 3596) exited, exit code 255 2009-09-29 14:28:55 HKT LOG: terminating any other active server processes 2009-09-29 14:28:55 HKT WARNING: terminating connection because of crash of another server process 2009-09-29 14:28:55 HKT 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. 2009-09-29 14:28:55 HKT HINT: In a moment you should be able to reconnect to the database and repeat your command. 2009-09-29 14:28:55 HKT WARNING: terminating connection because of crash of another server process 2009-09-29 14:28:55 HKT 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. 2009-09-29 14:28:55 HKT HINT: In a moment you should be able to reconnect to the database and repeat your command. 2009-09-29 14:28:55 HKT LOG: all server processes terminated; reinitializing 2009-09-29 14:28:56 HKT FATAL: pre-existing shared memory block is still in use 2009-09-29 14:28:56 HKT HINT: Check if there are any old server processes still running, and terminate them. I wonder about the line of “terminating connection because of crash of another server process”. I have done nothing else except starting up postgresql service. Well, that's a normal message when something crashes. The question is what's making it crash. Have you tried removing plugin_debugger.dll from the equation? Have you tried a fresh PostgreSQL install? Something's obviously different in your installation than elsewhere. ...Robert -- 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 #5039: 'i' flag i in regexp_replace ignored for polish letters
On Sat, Sep 5, 2009 at 5:42 AM, Kamil Roman kamil.lech.ro...@gmail.com wrote:
The following bug has been logged online:
Bug reference: 5039
Logged by: Kamil Roman
Email address: kamil.lech.ro...@gmail.com
PostgreSQL version: 8.3.7
Operating system: Windows XP
Description: 'i' flag i in regexp_replace ignored for polish letters
Details:
select regexp_replace('LUBŻKOĄŚĆĘŁŃÓ','[ośżźćęąłńó]',
'_','ig');
returns 'LUBŻK_ĄŚĆĘŁŃÓ' and it should return LUB_K___
I haven't seen a response to this. Anyone think this might be a bug?
...Robert
--
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 #5130: Failed to run initdb:1
On Thu, Oct 22, 2009 at 10:47 AM, flamin dragon flamindrag...@gmail.com wrote: 2009/10/22 Robert Haas robertmh...@gmail.com On Wed, Oct 21, 2009 at 12:51 PM, flamindrag...@gmail.com wrote: The following bug has been logged online: Bug reference: 5130 Logged by: Email address: flamindrag...@gmail.com PostgreSQL version: any Operating system: Win XP Pro SP2 Description: Failed to run initdb:1 Details: here's the log of the bug The files belonging to this database system will be owned by user SYSTEM. This user must also own the server process. The database cluster will be initialized with locale Polish_Poland.1250. initdb: could not find suitable text search configuration for locale Polish_Poland.1250 The default text search configuration will be set to simple. creating directory C:/Program Files/PostgreSQL/8.3/data ... ok creating subdirectories ... ok selecting default max_connections ... Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. 10 selecting default shared_buffers/max_fsm_pages ... Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. Nie moľna odnale«† okre˜lonego pliku. 400kB/2 creating configuration files ... ok creating template1 database in C:/Program Files/PostgreSQL/8.3/data/base/1 ... ok initializing pg_authid ... Nie moľna odnale«† okre˜lonego pliku. child process exited with exit code 1 initdb: removing data directory C:/Program Files/PostgreSQL/8.3/data Nie moľna odnale«† okre˜lonego pliku. = unable to find the file What's interesting to me is that I can't find that string anywhere in the PostgreSQL 8.3 sources. I think this must be an operating system error message. It looks like initdb is trying to invoke the postgres executable as a standalone backend, and failing. There is some code in initdb.c's main() routine which appears to be intended to prevent this from happening, or at least throw a less cryptic error message, but it's evidently not working for you for some reason. I speculate that this might be some kind of funky permissions issue, but I am not a Windows expert... ...Robert So, do you have any suggestions how to solve this or where I could get any help? Well, I'm sort of hoping one of the Windows folks will chime in here... but I would start by checking that PostgreSQL is in your path exactly once and that the permissions are set right. ...Robert -- 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 #5021: ts_parse doesn't recognize email addresses with underscores
On Fri, Aug 28, 2009 at 9:59 AM, Dan O'Hara danarasoftw...@gmail.com wrote:
The following bug has been logged online:
Bug reference: 5021
Logged by: Dan O'Hara
Email address: danarasoftw...@gmail.com
PostgreSQL version: 8.3.7
Operating system: win32
Description: ts_parse doesn't recognize email addresses with
underscores
Details:
In the following example,
select distinct token as email
from ts_parse('default', ' first_l...@yahoo.com ' )
where tokid = 4
ts_parse returns l...@yahoo.com rather than first_l...@yahoo.com It seems
that any text prior to the underscore is truncated. If the portion
following the underscore is only numeric, such as this example,
select distinct token as email
from ts_parse('default', ' bill_2...@yahoo.com ' )
where tokid = 4
then ts_parse returns nothing at all.
section 3.2.3 of RFC 5322 indicates that underscores are valid characters in
an email address.
http://tools.ietf.org/html/rfc5322
I don't think this has much to do with email addresses. If you do:
select token from ts_parse('a_b');
...you get three tokens. In your case you're pulling out the fourth
token, but some of your examples don't have four tokens, so then you
get nothing at all.
I'm not real familiar with ts_parse(), but I'm thinking that it
doesn't have any special casing for email addresses and is just
intended to parse text for full-text-search - in which case splitting
on _ is a pretty good algorithm.
...Robert
--
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 #5124: visualizacion de registros
2009/10/16 malu maluulam_l...@yahoo.com.mx: The following bug has been logged online: Bug reference: 5124 Logged by: malu Email address: maluulam_l...@yahoo.com.mx PostgreSQL version: 8.3 Operating system: windows xp proffeional Description: visualizacion de registros Details: Hola que tal, buen dia, veran estoy importando una archivo tipo CSV a una tabla de postgres, la importacion es correcta, la ejecuta bien , pero al momento de pedirle que muestre la informacion no muestra nada, considero yo que es por el numero de registros, ya que son 80 registros los que riene a tabla, no se si me puedan ayudar como hacer que se guardenbien los registros en la tabla para que pueda manipularla. Gracias por su atencion Saludos No estoy seguro que es el problema, pero sospecho que el numero to registros no importa. Sugiero que pregunte Ud. en pgsql-es-ay...@postgresql.org con los commands y las respuestas de PostgreSQL, porque en este mailing list se habla ingles. Ademas, creo que no es un bug sino una pregunta de usario. ...Robert -- 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 #5114: database initialization
On Wed, Oct 14, 2009 at 9:56 AM, flamindrag...@gmail.com wrote: The following bug has been logged online: Bug reference: 5114 Logged by: Email address: flamindrag...@gmail.com PostgreSQL version: any Operating system: Win XP Pro SP2 Description: database initialization Details: Hey I keep getting the failed to run initdb: 1 error every time I try to install any postgre. How can I solve this Well, for starters, you might check the log file... ...Robert -- 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 #5098: Levenshtein with costs is broken
On Tue, Oct 6, 2009 at 9:38 PM, Matthew Byrne matt...@hairybrain.co.uk wrote:
The following bug has been logged online:
Bug reference: 5098
Logged by: Matthew Byrne
Email address: matt...@hairybrain.co.uk
PostgreSQL version: 8.4.1
Operating system: Linux x86_64 (Ubuntu 9.04)
Description: Levenshtein with costs is broken
Details:
The Levenshtein with costs function in the fuzzystrmatch module is coded
incorrectly. The initial values in the distance matrix are set up as 0, 1,
2 etc. when they should be 0, deletion_cost, (2 * deletion_cost)... and 0,
insertion_cost, (2 * insertion_cost) etc. respectively. This causes the
function to return incorrect values, e.g.:
SELECT LEVENSHTEIN('ABC', 'XABC', 100, 100, 100)
returns 1 (the correct answer is 100).
To fix this, make the following changes to fuzzystrmatch.c:
Change line 244 from
prev[i] = i;
to
prev[i] = i * del_c;
and change line 255 from
curr[0] = j;
to
curr[0] = j * ins_c;
Can you submit this as a patch file?
...Robert
--
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] vacuumdb error
On Fri, Oct 16, 2009 at 6:39 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Thom Brown wrote: This is either a bug in vacuumdb with it not using the correct order, or postgres shouldn't be paying attention to the order of the keywords. In any case, it doesn't work. I've searched the postgres FAQs, TODO and mailing list archives, but can't find a mention of this. Thanks, fixed. We had the same bug with FREEZE and ANALYZE combination, which was fixed in April, but the order between FREEZE and VERBOSE was still incorrect. The fact that this is order-sensitive is just a trap for the unwary anyway. I wonder if we ought to implement a flexible options syntax like we did for EXPLAIN and COPY, though since I don't know of any new options that are needed here maybe it's not worth it. ...Robert -- 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 #5118: start-status-insert-fatal
On Fri, Oct 16, 2009 at 10:33 AM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Pedro Gimeno pgsql-...@personal.formauri.es wrote: Tom Lane wrote: This could be addressed by having the postmaster report its $PGDATA value in the pg_ping response, but I would be against that on security grounds. We don't let nonprivileged users know where PGDATA is, why would we make the information available without any authentication at all? Maybe a hash of it? I'm not really clear on why it's a security issue for someone to know the $PGDATA value, but if it is, there are some typical locations for which a hash could be generated and matched against the returned hash; so a hash of it would only be safe for those who chose sufficiently creative directory paths. On top of that, I'm not sure it's a very useful way to confirm that you've connected to the correct instance. We often get requests to replace the contents of a development or test database with a dump from a production database. More than once, the DBA doing this has forgotten to stop PostgreSQL before deleting the $PGDATA directory and creating it fresh for the restore of the PITR dump. When we attempt to start the new copy, which has the same $PGDATA, owner, and port number as the copy still running in the deleted directory, we have similar issues to those described in the original post. So, personally, I consider the data directory a less reliable test than the pid. (We don't have a lot of OS crash reboot occurrences.) Well, then Tom's idea of using a random number seems pretty solid no matter how you slice it. Maybe a UUID. ...Robert -- 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 #5118: start-status-insert-fatal
On Fri, Oct 16, 2009 at 11:08 AM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Robert Haas robertmh...@gmail.com wrote: Well, then Tom's idea of using a random number seems pretty solid no matter how you slice it. Maybe a UUID. A random number is looking like the best option. I'm not sure why I'd want to generate a perfectly good 128 bit random number and then throw away six of the bits to dress it up as a UUID, though. Do the libraries for that do enough to introduce entropy to compensate for the lost bits? Any other benefit I'm missing? I'm confused. UUIDs throw away 6 bits? Anyway, some smaller random number might be fine, too - not trying to throw a monkey wrench into the process. ...Robert -- 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 #5118: start-status-insert-fatal
On Fri, Oct 16, 2009 at 2:04 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Robert Haas robertmh...@gmail.com wrote: UUIDs throw away 6 bits? http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Version_4_.28random.29 How about that. You learn something new every day. ...Robert -- 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 #5083: Problem create account.
On Sun, Sep 27, 2009 at 5:29 PM, Jesper sol...@hotmail.com wrote: The following bug has been logged online: Bug reference: 5083 Logged by: Jesper Email address: sol...@hotmail.com PostgreSQL version: 8,3 Operating system: Vista Description: Problem create account. Details: Hello. I've been trying create an account with you. I need to get holdem manager to work. But when I create it cancel when I try to install. error Account already created or could't create I have vista. Does it not work then ? This doesn't sound like a bug; I'm guessing you've done something wrong, but I don't know what it is. You might want to contact whoever supports holdem manager and/or try this question (with more details) on pgsql-novice or pgsql-general. ...Robert -- 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 #5090: erro
On Wed, Sep 30, 2009 at 7:11 AM, Edinei edi...@guaporepecuaria.com.br wrote: The following bug has been logged online: Bug reference: 5090 Logged by: Edinei Email address: edi...@guaporepecuaria.com.br PostgreSQL version: 8.4 Operating system: Windows XP Description: erro Details: gerencio uma uma aplicação que tem como sgbd o postgresql 8.0, porém, ao migrar para o 8.4, quando tento executar uma rotina de atualização da aplicação onde está por sua vez cria novas tabelas, está gerando os seguintes erros: ERROR: out of shared memory HINT: You migth need to increase max_locks_per_transaction Gostaria de saber como resolver o problema. Att... Edinei edi...@guaporepecuaria.com.br ombedi...@hotmail.com This is an English mailing list. You might try here: https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Also, it would be helpful if you could say what you were doing when you got this error message. ...Robert -- 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 #5089: not supported plpsql
On Wed, Sep 30, 2009 at 4:33 AM, Yamashkin Alex defa...@smart-soft.ru wrote: The following bug has been logged online: Bug reference: 5089 Logged by: Yamashkin Alex Email address: defa...@smart-soft.ru PostgreSQL version: 8.4.0.1 Operating system: windows XP Embeded Description: not supported plpsql Details: good day. installing Postgresql 8.4 on Windows XP Embeded available language construct plpsql requests for functions. What is our problem and how it can solve? I'm not sure. Can you provide any more details? ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[SPAM?]Re: [BUGS] BUG #5089: not supported plpsql
On Wed, Sep 30, 2009 at 4:33 AM, Yamashkin Alex defa...@smart-soft.ru wrote: The following bug has been logged online: Bug reference: 5089 Logged by: Yamashkin Alex Email address: defa...@smart-soft.ru PostgreSQL version: 8.4.0.1 Operating system: windows XP Embeded Description: not supported plpsql Details: good day. installing Postgresql 8.4 on Windows XP Embeded available language construct plpsql requests for functions. What is our problem and how it can solve? I'm not sure. Can you provide any more details? Robert -- 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 #5088: community account not working
On Tue, Sep 29, 2009 at 11:15 PM, Ian Small i...@omniconnect.com.au wrote: The following bug has been logged online: Bug reference: 5088 Logged by: Ian Small Email address: i...@omniconnect.com.au PostgreSQL version: any Operating system: any Description: community account not working Details: Your postgresql.org community account PostgreSQL Webmaster [...@wwwmaster.postgresql.org] Sent: Tuesday, September 29, 2009 7:12 PM To: Ian Small Someone, probably you, has signed up for a postgresql.org community account. Please use the following details to log in to http://wwwmaster.postgresql.org/community/profile to change your password as soon as possible. So click on the I forgot my password link on this page... ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: Re[BUGS] g: 25P02, current transaction is aborted, commands ignored until end of transaction block
On Wed, Sep 30, 2009 at 5:23 AM, ajay labade ajaylab...@gmail.com wrote:
I am trying to port my application from Oracle to PostGREs. I have a
problem while doing so. In my application i need to update record if the
delete on the respective record is failed due to Constraint Violation. But
SQL Error: 0, SQLState: 25P02 ERROR [JDBCExceptionReporter] ERROR: current
transaction is aborted, commands ignored until end of transaction block is
being generated while updating the record. But with Oracle i am able to do
this.
I have tried with latest Jar [postgresql-8.3-604.jdbc3.jar] too, but
problem still exists.
Here is the code that i worked on:
try{
session = sessionManager.getSession();
transaction = session.beginTransaction();
session.delete(objects[i]);
session.flush();
}catch(ConstraintViolationException e){
objects[i].setDeleted(Integer.valueOf(1));
session.saveOrUpdate(object[i]);
session.flush();
}
transaction.commit();
sessionManager.closeSession(session);
This is not a bug.
When an exception occurs in PostgreSQL, any further commands are
ignored until the transaction is rolled back. In this case, you seem
to be catching a ConstraintViolationException and then attempting to
performing further database actions, which is bound to fail.
You may want to ROLLBACK within your exception handler and then BEGIN again.
...Robert
--
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 #5081: ON INSERT rule does not work correctly
On Mon, Sep 28, 2009 at 10:12 AM, Jacques Caron j...@oxado.com wrote: Hi, You can use a trigger before insert and a pl/pgsql function that goes: BEGIN UPDATE table SET ... WHERE pk=NEW.pk IF FOUND THEN RETURN NULL; ELSE RETURN NEW; END IF; END; Jacques. That seems about right. It's possible that the UPDATE could fail to find any rows but the INSERT could still fail due to a duplicate key violation (consider, for example, doing inserts for the same not-previously-exstant PK value in two different transactions, and then trying to commit each one). But I don't believe there's any way to completely prevent that sort of problem in a concurrent environment short of serializing all work behind a table lock, so the best we can do is try to make errors rare and avoid silent failures, which this should do. ...Robert -- 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: 答复: [BUGS] Encounter shared memory error whe n running createlang command!
On Mon, Sep 28, 2009 at 2:51 AM, Yaming Gu yaming...@w-oasis.com wrote: Thank you so much for your kind reply. Your analysis sounds very reasonable. I checked my Perl version, it is Perl 5.8.9 Build 826 which is the latest version in the series of 5.8.*. The whole process of installation of Perl goes well without any something wrong. And I can run Perl command out of Postgresql very well. So is this Perl version not compatible with Postgresql 8.3.7? And may I configure Perl somewhere or something? When Perl is loaded, what will be executed by it? Substitution pattern not terminated at line 1. Souds like one regular expression. But I can not determine what will be executed by Perl. BR Lucy Did you try loading plperlu? ...Robert -- 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 #5081: ON INSERT rule does not work correctly
On Sat, Sep 26, 2009 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote: Stefan s...@drbott.de writes: The problem is that if it is no record in the table, it seems that first the INSERT command is issued and after that the UPDATE command is issued, too. Well, yeah. That's exactly how it's documented to work: an ON INSERT rule is executed after the INSERT proper. I'm confused. DO INSTEAD doesn't mean DO INSTEAD? You could maybe make this work with a BEFORE INSERT trigger. I'm not sure you can make it reliable though. ...Robert -- 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 #5081: ON INSERT rule does not work correctly
On Sun, Sep 27, 2009 at 11:36 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Sat, Sep 26, 2009 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote: Well, yeah. That's exactly how it's documented to work: an ON INSERT rule is executed after the INSERT proper. I'm confused. DO INSTEAD doesn't mean DO INSTEAD? It does. What it doesn't mean is IF ... THEN ... ELSE The OP's rule actually works more like if (!(EXISTS ...)) INSERT ... if ((EXISTS ...)) UPDATE ... reads section 36.3 of the fine manual OK, I get it now. You could maybe make this work with a BEFORE INSERT trigger. I'm not sure you can make it reliable though. Concurrent inserts make things even more interesting, yes; but the rule had no hope of handling that anyway. OK. Sometimes when I've needed to do this I've written a PL/pgsql function that tries the insert and then fails over to an UPDATE if the INSERT fails due to a unique-violation. I'm not sure that's 100% robust either, though, unless using serializable mode. ...Robert -- 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 #5082: I can't get logfile( achive )
On Fri, Sep 25, 2009 at 11:50 AM, smuffy vday1...@gmail.com wrote: The following bug has been logged online: Bug reference: 5082 Logged by: smuffy Email address: vday1...@gmail.com PostgreSQL version: 8.4.0 Operating system: opensuse 10.2 Description: I can't get logfile( achive ) Details: hello. My DB can't make a logfile( archive ). But archive_mode is on.(postgresql.conf) How I get a logfile? help me, please. This isn't a bug; it's a usage question that should be posted to pgsql-general or pgsql-novice. Probably the first thing you want to do is look through your server logs and see if there are any informative error messages in there, or any indication of archiving activity. One possibility is that you aren't generating very much WAL activity, so it's taking a very long time between archive files. You could try issuing an explicit CHECKPOINT or setting archive_timeout. ...Robert -- 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] Encounter shared memory error when running createlang command!
On Wed, Sep 23, 2009 at 11:44 PM, Yaming Gu yaming...@w-oasis.com wrote: 2009-09-24 10:50:55 HKT LOG: loaded library $libdir/plugins/plugin_debugger.dll 2009-09-24 10:50:59 HKT LOG: loaded library $libdir/plugins/plugin_debugger.dll Substitution pattern not terminated at line 1. I'm very suspicious of this error message. Substitution pattern not terminated at line 1 sounds like an error message that is being generated *by Perl*. I don't see that phrase anywhere in the PostgreSQL sources. If that's true, that means that Perl is getting loaded, but then immediately dying when it tries to compile something-or-other that has a bad regular expression in there. Could there be something wrong with your Perl installation? Can you launch Perl from outside PostgreSQL OK? Another possibility is that some of the Perl code that PL/perl tries to execute during the load of Perl is not working for some reason. What version of Perl do you have on your system? What happens if you try to load plperlu? ...Robert -- 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 #5071: abbrev() bug with IPv6
On Tue, Sep 22, 2009 at 12:54 AM, alexander.o...@koeln.de wrote:
The following bug has been logged online:
Bug reference: 5071
Logged by:
Email address: alexander.o...@koeln.de
PostgreSQL version: 8.3.7
Operating system: Debian Lenny 64Bit
Description: abbrev() bug with IPv6
Details:
I have a Database to store IPV6 addresses.
Field net is type cidr.
e.g.: '2001:400::/32' as value.
SELECT abbrev(net) FROM ipstore;
expected result: 2001:400::/32 (its already short v6)
actual result: 2001:400/32 wich is invalid v6 Syntax.
I think this is the expected behavior. The same thing happens with IPv4.
rhaas=# select abbrev('216.83.114.0/24'::cidr);
abbrev
---
216.83.114/24
(1 row)
It's also documented this way in the fine manual.
http://www.postgresql.org/docs/current/static/functions-net.html#CIDR-INET-FUNCTIONS-TABLE
You can get the behavior you want by casting your cidr to an inet
before applying abbrev.
...Robert
--
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] Databse installation problem
On Mon, Sep 21, 2009 at 1:53 AM, Bhushan Verma verma.bhus...@gmail.com wrote: I have tried to install postgres version 8.3.7 as follows rm -rf /var/lib/pgsql mkdir /var/lib/pgsql ./configure --prefix /var/lib/pgsql gmake su gmake install adduser postgres mkdir /var/lib/pgsql/data chown postgres /var/lib/pgsql/data su - postgres /usr/local/pgsql/bin/initdb -D /var/lib/pgsql/data /usr/local/pgsql/bin/postgres -D /var/lib/pgsql/data pgstartup.log 21 /usr/local/pgsql/bin/createdb test /usr/local/pgsql/bin/psql test then i log on database to see the version test= select version(); version --- PostgreSQL 8.3.1 on i386-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.3.0 20080314 (Red Hat 4.3.0-3) (1 row) but its showing me 8.3.1 that was my previous version. Could anyone tell me what is the problem. You still have the old version in your PATH variable, and before the new version. ...Robert -- 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] PROBLEMA AL INSTALAR POSTSGRESQL
2009/9/17 Paola R. griffindor_2...@hotmail.com buenas tardes estoy tratando de instalar postgresql 8.2 pero en la parte initialise databasecluster cuando ingreso un el password al dar next me sale el siguiente mensaje: the secondary logon service is not running. this service is required for the installer to initialize the database. please start this service and try again. pero no se que quiere hacer. en otro caso mesale que no sepeude crear en usuario pero no me deja eliminarlo. por favor necesito ayuda. Tal vez Ud. debe tratar tu pregunta aqui'. http://archives.postgresql.org/pgsql-es-ayuda/ Aqui en este mailing list no hablamos espan~ol. Ademas, no es un bug sino una pregunta de usario. Pero creo que necessita cambiar los settings del servicio secondary login, para empezarlo automaticamente. (with apologies to anyone on this mailing list who ACTUALLY speaks Spanish - it must have hurt to read that) ...Robert -- 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 #5075: Text Search parser does not identify xml tag when attribute name's contains underscore
On Wed, Sep 23, 2009 at 7:31 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Marek Lewczuk escreveu:
Please execute following example:
select * from ts_debug('english', 'img width=182 height=120
align=right style=margin: 0px 0px 5px 5px; test_aa=26461/')
As the result you will see, that img/ is not identified as XML tag, but
rather splitted as words, blank spaces etc. The reason for that is the fact,
that last attribute test_aa contains underscore in its name - when the
underscore is removed, then img tag is properly identified as XML tag.
XML definition allows using underscore in tag and attribute names.
The problem is we already allow it in tag names but not in attribute names. So
the proper fix is to allow underscore when the state is TPS_InTag; according
to XML spec [1], the underscore is a valid character in attribute names.
A possible downside is that we don't have underscores in HTML attribute names.
In this case, should it fail? I don't think so but...
The problem exists in 8.3, 8.4 and HEAD. It is a trivial fix so I think there
isn't a problem to back-patch it.
This patch should probably be added to
https://commitfest.postgresql.org/action/commitfest_view/open so that
we don't lose track of it.
...Robert
--
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] Encounter shared memory error when running createlang command!
2009/9/23 Yaming Gu yaming...@w-oasis.com Hi, List Because I need to use pl/perl language, then I decided to run “createlang” to create PL/Perl language. I have checked all dependencies and all is ok. Next I run: D:\Program Files\Postgresql\bincreatelang �CU postgres plperl example (example is my dbname) Then it failed telling me: createlang: language installation failed: 服务器意外地关闭了联接 这种现象通常意味着服务器在处理请求之前 或者正在处理请求的时候意外中止 I checked my log and show it below: ** 2009-09-23 13:39:55 HKT LOG: loaded library $libdir/plugins/plugin_debugger.dll 2009-09-23 13:39:58 HKT LOG: loaded library $libdir/plugins/plugin_debugger.dll Substitution pattern not terminated at line 1. 2009-09-23 13:39:59 HKT 日志: 服务器进程 (PID 5588) 已退出, 退出代码 255 2009-09-23 13:39:59 HKT 日志: 中断任何其它已激活的服务器进程 2009-09-23 13:39:59 HKT 日志: 所有的服务器进程被中止; 重新初始化 2009-09-23 13:40:00 HKT 致命错误: pre-existing shared memory block is still in use 2009-09-23 13:40:00 HKT 提示: Check if there are any old server processes still running, and terminate them. ** Can you give me some advice about this problem? Hmm... I confess I'd have an easier time if this were all in English. ...Robert
Re: [BUGS] BUG #5066: plperl issues with perl_destruct() and END blocks
On Mon, Sep 21, 2009 at 7:30 PM, Tom Lane t...@sss.pgh.pa.us wrote: David Fetter da...@fetter.org writes: On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote: With connection poolers, backends can last quite awhile. Is it OK for the END block to run hours after the rest of the code? This is an interesting point -- should END blocks be called on DISCARD ALL? ENOCLUE And in the same vein, should they be called inside a transaction, or not? What if they fail? I don't see any reason whatsoever that we couldn't just document this as a Perl feature not supported in plperl. If you do something like creating threads inside plperl, we're going to give you the raspberry when you complain about it breaking. END blocks can perfectly well go into the same category. If the changes are simple, as Tim seems to believe, exactly what do we lose by doing this? ...Robert -- 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 #5066: plperl issues with perl_destruct() and END blocks
On Tue, Sep 22, 2009 at 10:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If the changes are simple, as Tim seems to believe, exactly what do we
lose by doing this?
It's not simple. There are any number of issues that Tim has not
addressed. The most obvious: *his* use case might not require database
access in an END block, but that doesn't mean the next complainant won't
want it.
Well, that's a reason why you might have to say no to the next
complainant, but not necessarily the current one.
Another point that comes to mind is shared_preload_libraries: if plperl
is loaded once in the postmaster, it seems entirely likely that the same
END block would be executed in multiple backends after having been
loaded only once. Again, while that might be okay for his particular
use-case, it seems horribly dangerous for anything else.
Regular perl has the same problem, so any perl modules that are
counting on any other behavior are already broken.
$ perl -e 'fork(); END { print hi\n }'
hi
hi
(The shared_preload_libraries case also destroys the most obvious
implementation path, ie having plperl add an on_proc_exit callback
at _PG_init time...)
Can't comment on that.
But my basic objection is that a PL is a device for executing code in
functions. It has no business being used to cause action at a
distance outside of those functions. If we go down this path we are
going to regret it.
I agree with that concern, but if this were already implemented the
way that Tim wants it, we would be unlikely to change it to the way
that it is now on that basis. In practice, I don't think anyone uses
END {} blocks for anything terribly elaborate, because it falls over.
They are however useful for things like dumping debugs or profiling
statistics, and I don't see much reason to prevent those sorts of
uses. I also think that to some degree the horse has already left the
barn on this one: if the Perl interpreter isn't being destroyed until
backend exit, that implies that you can ALREADY do all kinds of
horrible things, like setting global variables and reading them back
later. What happens if you call fork(), or pthread_create(), or
modify %SIG?
...Robert
--
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] Problem installing Postgres 8.4.1
On Mon, Sep 21, 2009 at 3:23 PM, Christine Penner christ...@ingenioussoftware.com wrote: At 11:57 AM 21/09/2009, you wrote: What error you get when you run initdb?? (Also what exact command you run?) The first time I just double clicked on the file initdb.exe. Just now I tried to run it through the command prompt and go this, this is the same stuff that was in the log file in the temp directory after I ran the installer: C:\Program Files\PostgreSQL\8.4\bininitdb.exe -D C:\PostgreSQL\8.4\data The files belonging to this database system will be owned by user User. This user must also own the server process. The database cluster will be initialized with locale English_Canada.1252. The default database encoding has accordingly been set to WIN1252. The default text search configuration will be set to english. fixing permissions on existing directory C:/PostgreSQL/8.4/data ... ok creating subdirectories ... initdb: could not create directory C:/PostgreSQL: File exists initdb: removing contents of data directory C:/PostgreSQL/8.4/data C:\Program Files\PostgreSQL\8.4\bin I deleted the PostgreSQL Directory that was there (empty) and tried again and now it tells me that initdb.exe is not a valid win32 application It sort of sounds like you must've removed some component that initdb.exe needed but I'm not a Windows guy, so just speculating. ...Robert -- 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 #5066: plperl issues with perl_destruct() and END blocks
On Mon, Sep 21, 2009 at 12:06 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: David Fetter escribió: Taken literally, that would mean, the last action before the backend exits, but at least to me, that sounds troubling for the same reasons that end of transaction triggers do. What happens when there are two different END blocks in a session? The manual is clear that both are executed. With connection poolers, backends can last quite awhile. Is it OK for the END block to run hours after the rest of the code? This is an interesting point -- should END blocks be called on DISCARD ALL? It seems pretty reasonable that it would. The intention of DISCARD ALL is to completely reset the entire session. ...Robert -- 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 #5053: domain constraints still leak
On Mon, Sep 21, 2009 at 12:31 PM, Bruce Momjian br...@momjian.us wrote: Sam Mason wrote: On Mon, Sep 14, 2009 at 10:54:07AM -0500, Kevin Grittner wrote: Sam Mason s...@samason.me.uk wrote: the deeper problem seems to be that the table was created as: create table test (a tstdom); and not as: create table test (a tstdom not null); Given that tstdom is declared as NOT NULL, is this difference considered a *feature* or is it an implementation quirk? That's why I pointed it out! Based on my reading of the SQL spec (and reading about Codd's descriptions of domains) I'd say it was a bug/implementation quirk. Do we need a TODO for this item? Also, I see this odd behavior even without domains: test= CREATE TYPE xx AS (x INT); CREATE TYPE test= CREATE TABLE test4(col1 xx NOT NULL); CREATE TABLE test= INSERT INTO test4 VALUES (ROW(NULL)); INSERT 0 1 test= SELECT * FROM test4 WHERE col1 IS NULL; col1 -- () (1 row) Here I am illustrating that NOT NULL and IS NULL have different ideas of what a NULL is? That seems odd too. I think what you're demonstrating is that there is a difference between a NULL, and a row consisting of a single NULL. We've had some dispute (on this thread) about whether that ought to be the case, but this is certainly a lot less weird and more debatable than the domain example, at least IMO. ...Robert -- 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 #5066: plperl issues with perl_destruct() and END blocks
On Mon, Sep 21, 2009 at 2:17 PM, David Fetter da...@fetter.org wrote: On Mon, Sep 21, 2009 at 01:06:17PM -0400, Alvaro Herrera wrote: David Fetter escribió: On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote: David Fetter escribió: Taken literally, that would mean, the last action before the backend exits, but at least to me, that sounds troubling for the same reasons that end of transaction triggers do. What happens when there are two different END blocks in a session? The manual is clear that both are executed. So it is, but does order matter, and if so, how would PostgreSQL know? The fine manual saith You may have multiple END blocks within a file--they will execute in reverse order of definition; that is: last in, first out (LIFO). But then, why would we care? We just call the destructor and Perl ensures that the blocks are called in the right order. This is not quite what I meant. Let's say we have two or more different PL/Perl functions executed over the course of a backend. Which one's END block gets executed last? Do we need to warn people about this? Generate a WARNING, even? This is a feature of the Perl language. I don't think it's our job to second-guess the language design, however good or bad it may be. As a long-time Perl programmer, I would certainly say that if you are counting on the execution ordering of your END blocks, you are probably playing with fire and likely ought to rethink your application design, because there are all kinds of ways this could fail spectacularly as a result of apparently innocuous application changes (like, say, alphabetizing the list of use declarations in some package). But that's true not only with PL/perl but with just plain old perl, and I don't see that it's substantially more dangerous here than anywhere else. ...Robert -- 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 #5066: plperl issues with perl_destruct() and END blocks
On Mon, Sep 21, 2009 at 3:08 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
David Fetter escribió:
On Mon, Sep 21, 2009 at 01:06:17PM -0400, Alvaro Herrera wrote:
The fine manual saith
You may have multiple END blocks within a file--they will
execute in reverse order of definition; that is: last in, first
out (LIFO).
But then, why would we care? We just call the destructor and Perl
ensures that the blocks are called in the right order.
This is not quite what I meant. Let's say we have two or more different
PL/Perl functions executed over the course of a backend. Which one's
END block gets executed last?
I think the manual is quite clear on this point. It talks about files
which we don't have, but other than that it doesn't seem like there
shouldn't be any problem.
Now that I think about it, this only affects loaded modules, not the
plperl functions themselves, right? I mean, you can't define an END
block inside a function.
You might think that, but it turns out the world of Perl is crazier
than the ordinary mind can fathom.
$ perl -e 'sub foo { END { print hi\n } }'
hi
...Robert
--
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 #5066: plperl issues with perl_destruct() and END blocks
On Sat, Sep 19, 2009 at 3:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Tim Bunce tim.bu...@pobox.com writes:
The plperl implementation doesn't call perl_destruct() during server
shutdown.
Who cares? The process is going away anyway.
END {} blocks can execute arbitrary code. Perl users will expect them
to be executed.
...Robert
--
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 #5063: MS Access crashes by quiting after linking tables with PostgreSQL
On Fri, Sep 18, 2009 at 5:45 AM, Annita annita.ven...@qs-unisolution.com wrote: The following bug has been logged online: Bug reference: 5063 Logged by: Annita Email address: annita.ven...@qs-unisolution.com PostgreSQL version: 8 Operating system: Windows Description: MS Access crashes by quiting after linking tables with PostgreSQL Details: MS Access (2003,2007) crashes by closing down , after i have linked the tables of my postgreSQL database. I cannot find anything relevant with this problem. I have tried everything, the problem has to do with the postgredriver since this doesnt happen when i connect with MySql or SQL. CAN ANYONE HELP??? please??? I think you probably need to provide a lot more detail about what you are doing for anyone to have a chance of helping you with it. ...Robert -- 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] Wrong default values of columns
On Thu, Sep 17, 2009 at 8:15 AM, Andre Rothe pho...@gmx.de wrote: Hi, I have installed Postgres 8.3.8 on Fedora Linux. If I create a table, the default values will be set by the database to NULL::timestamp without time zone for a timezone column and to NULL::character varying for a varchar column. How I can prevent such a behaviour? Both column defaults should be NULL. Uh... that's exactly what they were set to. The :: stuff is just a type-annotation. Your defaults really are NULL. I have read some posts about this point, it seems to be a problem of a so called acts_as_tsearch plugin, but I'm not familiar enough with Postgres to know, what it means. Any other detailled solutions? I don't think that has anything to do with this. ...Robert -- 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] Wrong default values of columns
On Thu, Sep 17, 2009 at 10:44 AM, Andre Rothe pho...@gmx.de wrote: The problem is, that I get the default values from a metadata query with JDBC, so I have to parse every return value for such an annotation before I can use them. That sounds annoying, but it's not a PostgreSQL bug. So it seems that I could change the jdbc driver to a newer version. I use the PostgreSQL 8.1 JDBC3 with SSL (build 407). I don't really know anything about the JDBC driver, but the closest thing I see here: http://jdbc.postgresql.org/download/ ...is a link to http://jdbc.postgresql.org/download/postgresql-8.1-407.jdbc3.jar, with a date of 23-May-2006. So yeah, updating might be a good idea. If you're still on PG 8.1, updating that might be a REALLY good idea, though it probably won't do anything for you on this particular issue. I would suggest asking on pgsql-jdbc; not too many jdbc folks reading this list, AFAICT. ...Robert -- 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 #5059: Planner ignores estimates when planning an IN () subquery
On Tue, Sep 15, 2009 at 11:35 PM, Kenaniah Cerny kenan...@gmail.com wrote: The following bug has been logged online: Bug reference: 5059 Logged by: Kenaniah Cerny Email address: kenan...@gmail.com PostgreSQL version: 8.4.1 Operating system: Centos5.2 Description: Planner ignores estimates when planning an IN () subquery Details: Consider the following query: http://pgsql.privatepaste.com/aa5DAtiwws When planning the subquery of the IN () statement, the planner chose to scan the indexes of the outer and inner columns in parallel using a nested loop semi join. http://pgsql.privatepaste.com/4eXj3zRcy7 By not enabling the planner to sort via the index of the outer column in the WHERE clause (query above), the a nested loop version of the plan executes in a fraction of the time. http://pgsql.privatepaste.com/5c0bOcL3t6 As you can see from the above query, forcing the materialization of the subquery produces a much superior plan. http://pgsql.privatepaste.com/371nl6KFrI For comparison, this query replaces the subquery with hard-coded values. The planner appears to not be weighing the benefits of materializing the subquery of the IN () statement properly when ordering is involved, and still produces an inferior plan when ordering is not a factor. Please feel free to contact me for additional test cases if needed. I've seen this kind of plan before. The planner knows that a backwards index scan over user_activity_log is slow, but it thinks that it won't have to scan very much of it because it will accumulate enough rows to satisfy the LIMIT before it goes very far. When it turns out that there are not as many matching rows in user_friends as anticipated, things get very slow. Unfortunately, there's not an easy solution to this problem. If it were really true that most rows in user_activity_log had matches in user_friends, then planner would be correct to choose the plan it did - and wrong to choose the plan you want it to use. In this case, your table is small enough that a bitmap heap scan on user_activity_log is reasonable, but for a larger table in a situation where the join selectivity is higher, it might really be necessary to use the index. The problem is just that the planner is doing a poor job figuring out where the breakpoint is between those two strategies. I'm not 100% sure exactly which selectivity estimate is wrong. It's not clear to me whether things are already wrong here: INDEX Scan USING user_friends_user_account_id_friend_id_key ON user_friends (cost=0.00..0.27 rows=1 width=4) (actual time=0.004..0.004 rows=0 loops=350713) But they're definitely wrong here: Nested Loop Semi JOIN (cost=0.00..144564.33 rows=62298 width=52) (actual time=5138.961..5405.075 rows=10 loops=1) I *think* the root cause of the problem is that we don't have multi-column statistics. When you look at user_friends, we can tell you the selectivity of user_friends.user_account_id = 74650 pretty accurately, and we should also be able to spit out MCVs to compare against the MCVs of user_activity_log, but if the selectivity of those two expressions together doesn't resemble the product of their individual selectivities, which is probably the case here, the planner has no way to detect that. ...Robert -- 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 #5059: Planner ignores estimates when planning an IN () subquery
On Wed, Sep 16, 2009 at 6:39 PM, Kenaniah Cerny kenan...@gmail.com wrote: I can provide the output of statistics queries if you would like. Just let me know which statistics you want and I'll pastebin them. As far as selectivity goes, the selectivity estimate for the user_anime_log.user_account_id was definitely miscalculated. The user_anime_log contains up to 15 entries per user (70,000 users, but only 475,811 rows). The default statistics target on that relation is set to 1000. But even with poor statistics, guessing 62,000 rows when there's a maximum of 15 per user account is still quite a miss. You've changed the table name on me, vs. what you pasted in the query, which had a user_activity_log but no user_anime_log... Analysis of SELECT * FROM user_activity_log WHERE user_account_id = 17238; estimates 13 rows and returns 15, which is quite reasonable considering the statistics targets. Please forgive my ignorance, but in the case of my subquery, is the estimated number of rows and cost being taken into account (or only the selectivity)? Well, selectivity is just a term that refers to the fraction of rows that match some condition (rows themselves do not have selectivity). Usually the initial estimating is done in terms of selectivity, which is then multiplied by the total number of rows to find the number of rows that will remain after the condition is applied. So, yes, rows and cost are taken into account. The problem here is that the planner is mis-estimating the selectivity, therefore it computes the wrong number of rows (way too high), therefore it makes the wrong decision. Granted I don't understand much about the planner internals, but it seems strange that a nested loop semi join would be chosen when the inner table is estimated to return an extremely low number of rows with low cost and low selectivity. Shouldn't the planner also estimate the cost of an inner (er, left?) join in that scenario? Well... you can't replace a semi join with an inner or left join, because it doesn't do the same thing. You could use a hash semi join or merge join semi join, but that doesn't make sense if, as you say, the inner table is estimated to return an extremely low number of rows. It might be a bit easier to analyze this if you stripped out all the joins that aren't necessary to reproduce the problem. Also, I would prefer EXPLAIN ANALYZE output posted in-line to the mailing list rather than pasted to a separate web site - it screws up the formatting. But honestly I'm not sure how much time it's worth spending on this. You have a way to rewrite the query that works... and fixing the estimator is going to be hard... so I suggest doing it the way that works, and moving on! ...Robert -- 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] error: message type 0x5a arrived from server while idle
On Tue, Sep 8, 2009 at 11:38 PM, vyou zhi vyou...@gmail.com wrote:
hi all:
i use Python and PyGreSQL to link PostgreSQL
but the Python give me the error
the error here :
...
95
93
95
97
94
96
94
message type 0x43 arrived from server while idle
message type 0x5a arrived from server while idle
INSERT INTO code (stock_name ,stock_code)values('b','b')
95
93
92
93
99
and the PostgreSQL log error like here
---
...
LOG: unexpected EOF on client connection
This sounds like a bug in PyGreSQL. Maybe it's not following the FE
protocol correctly?
...Robert
--
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] GIN needs tonic
On Tue, Sep 15, 2009 at 4:41 PM, Simon Riggs si...@2ndquadrant.com wrote: I guess if you or another committer spends some time writing a test framework that is useful and that you can trust, I'm sure many people will add to it. That'll be true for any of the major/complex areas not covered by public test suites: concurrency, recovery and the optimizer. +1! ...Robert -- 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 #5058: [jdbc] Silent failure with executeUpdate()
On Tue, Sep 15, 2009 at 3:26 PM, Joseph Shraibman j...@selectacast.net wrote: The following bug has been logged online: Bug reference: 5058 Logged by: Joseph Shraibman Email address: ...@selectacast.net PostgreSQL version: 8.2.14 Operating system: Linux Description: [jdbc] Silent failure with executeUpdate() Details: Based on the lack of response to previous JDBC/ODBC bugs on this list, I'm guessing you should try posting this to pgsql-jdbc rather than pgsql-bugs. ...Robert -- 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 #5042: Update numeric within a rule
On Sun, Sep 6, 2009 at 4:48 PM, Ilian Georgiev georgiev.il...@gmail.com wrote: The following bug has been logged online: Bug reference: 5042 Logged by: Ilian Georgiev Email address: georgiev.il...@gmail.com PostgreSQL version: 8.1.10 Operating system: Windows XP Description: Update numeric within a rule Details: Hello I have a sutuation where I can do update on numeric column with a signle update but when this update statement is in a rule it doesn't wotk properly. Look : I have a table with videos : CREATE TABLE video ( video_sid SERIAL PRIMARY KEY, category_sid int NOT NULL REFERENCES category ON UPDATE RESTRICT ON DELETE RESTRICT, url varchar(32) NOT NULL, user_sid int NOT NULL REFERENCES user ON UPDATE RESTRICT ON DELETE RESTRICT, image_sid int REFERENCES image, creation_datetime timestamp NOT NULL DEFAULT NOW(), view_count int NOT NULL DEFAULT 0, comment_count int NOT NULL DEFAULT 0, rating numeric(4,2) NOT NULL DEFAULT 0, rating_percent int NOT NULL DEFAULT 0, votes int NOT NULL DEFAULT 0, is_published boolean NOT NULL DEFAULT false, title varchar(128) NOT NULL, description text ); GRANT INSERT, UPDATE, SELECT ON video TO web; GRANT SELECT, UPDATE ON video_video_sid_seq TO web; COMMENT ON TABLE video IS 'Holds video desctiptions'; CREATE OR REPLACE FUNCTION update_rating_percent() RETURNS trigger AS $BODY$ BEGIN IF (NEW.rating!=0) THEN NEW.rating_percent := ((NEW.rating / 5 ) * 100)::int; END IF; RETURN NEW; END; $BODY$ LANGUAGE 'plpgsql' VOLATILE; GRANT EXECUTE ON FUNCTION update_rating_percent() TO web; CREATE TRIGGER update_rating_percent_trg BEFORE UPDATE ON video FOR EACH ROW EXECUTE PROCEDURE update_rating_percent(); and table with votes : CREATE TABLE video_vote ( video_sid int NOT NULL REFERENCES video ON UPDATE CASCADE ON DELETE CASCADE, ip_address inet NOT NULL, rate int NOT NULL CHECK (rate 0 AND rate 6), creation_datetime timestamp NOT NULL DEFAULT NOW() ); GRANT INSERT, UPDATE, DELETE, SELECT ON video_vote TO web; COMMENT ON TABLE video_vote IS 'Votes of every user by IP address'; CREATE UNIQUE INDEX video_vote_ukey ON video_vote (video_sid, ip_address); with a rule connected to the video table : CREATE OR REPLACE RULE video_vote_insert_rule AS ON INSERT TO video_vote DO ALSO UPDATE video SET votes = votes + 1, rating = (( SELECT SUM(rate)::numeric FROM video_vote WHERE video_sid = NEW.video_sid ) / (votes + 1) )::numeric WHERE video_sid = NEW.video_sid; now when I do simple update on video it gets the right value for scale.But when I do insert on video_vote and this do update on video table I got .00 for scale. I think what is happening here is that you are dividing two integers (rate is an integer, therefore sum(rate) is an integer, and votes is an integer, therefore votes + 1 is an integer), so you're getting an integer result. You then cast that result to a numeric, but by that point you've already thrown away the remainder. If you divide by votes::numeric + 1 instead of votes + 1 you'll probably get a different answer. I even changed my rule to : CREATE OR REPLACE RULE video_vote_insert_rule AS ON INSERT TO video_vote DO ALSO UPDATE video SET rating = 2.95 WHERE video_sid = NEW.video_sid; The result in rating column was 2.00 . I find this just about impossible to believe. I just tried it with a self-contained test case and it worked fine (see below). It's pretty hard to believe that there could be a bug that makes numeric division truncate to the nearest integer, but only when used from within a rule. I think it's more likely that you made a mistake somewhere in the process of carrying out this experiment. rhaas=# create table foo (id serial primary key, rating numeric(4,2) not null default 0); NOTICE: CREATE TABLE will create implicit sequence foo_id_seq for serial column foo.id NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index foo_pkey for table foo CREATE TABLE rhaas=# create table bar (id serial primary key); NOTICE: CREATE TABLE will create implicit sequence bar_id_seq for serial column bar.id NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index bar_pkey for table
Re: [BUGS] BUG #5053: domain constraints still leak
On Sun, Sep 13, 2009 at 10:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: Andrew Gierth and...@tao11.riddles.org.uk writes: Domain NOT NULL constraints (and probably other constraints too) aren't being enforced in some code paths. e.g. The example you give seems to tie really closely into the debate about whether a composite null is identically the same thing as ROW(NULL,NULL) or not. In short, we have It seems like regardless of this discussion you oughtn't to be able to store a NULL into that table column. But maybe I'm just confused. ...Robert -- 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 #5046: java developer
On Wed, Sep 9, 2009 at 5:42 AM, mahmoud badr alien_...@yahoo.com wrote: The following bug has been logged online: Bug reference: 5046 Logged by: mahmoud badr Email address: alien_...@yahoo.com PostgreSQL version: 8.4 Operating system: windows Description: java developer Details: when trying to create POJOs from Netbeans IDE they aren't ceated when the DBMS is postgreSQL and they are created if the DBMS is any thing else. please correct me if i'm wrong. I have no idea, but this sounds like something you need to talk to whoever makes your Netbeans IDE about, rather than the PostgreSQL developers. If you think there's a PostgreSQL bug here you need to tell us what actual SQL statements got executed, what you thought should happen, and what actually happened. ...Robert -- 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 #5053: domain constraints still leak
On Mon, Sep 14, 2009 at 10:22 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: It seems like regardless of this discussion you oughtn't to be able to store a NULL into that table column. But maybe I'm just confused. The system is relying on the not-unreasonable assumption that if it extracts a column of type X from someplace, what it has is a valid value of type X. Depending on what we decide about the whole composite-null mess, maybe we will be forced to abandon that assumption ... but I'm sure not going to do so until my back is to the wall. I haven't read the code in this area, but for what it's worth, I guess I lean toward the view that treating a row of NULLs as being the same thing as an undecorated NULL does not make very much sense. If I have a table row which contains (1, NULL, NULL) and I update the first column to be NULL, I feel like I now have (NULL, NULL, NULL), not just NULL. Every other programming language I'm aware of makes this distinction - for good reasons - and I don't really see any reason why SQL should do anything different. Under that view, null::test is not itself a test, but denotes the absence of one. Trying to store this value in a table can either fail outright (on the theory that you can't store the absence of something in a table), or else we can - as a special case - treat assignment from null to an actual object as a request to assign null to each column (which will fail if there exists a column into which a NULL of the associated column type can't be stored). ...Robert -- 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 #5047: Not able to connect from Informatica
On Thu, Sep 10, 2009 at 7:17 AM, Rohan jamadagni rohan.jamada...@tcs.com wrote: The following bug has been logged online: Bug reference: 5047 Logged by: Rohan jamadagni Email address: rohan.jamada...@tcs.com PostgreSQL version: 8.3.7 Operating system: Linux Rhel 5.0 Description: Not able to connect from Informatica Details: Hi We are trying to connect informatica(on HP-ux) to postgres server with ODBC driver while configuring we are facing following error 1.For psqlodbc-08.04.0100 pg_config not found (set PG_CONFIG environment variable) 2.For psqlodbc-08.01.0200 error: no suitable ODBC driver manager found Please help us resolve the same This sounds like a user question, not a bug. You might want to try here: pgsql-o...@postgresql.org http://archives.postgresql.org/pgsql-odbc/ ...Robert -- 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 #5056: SQLDescribeColW for function returning a result set incorrectly setting sql_nullable
On Mon, Sep 14, 2009 at 10:40 PM, the6campbells the6campbe...@gmail.com wrote:
The following bug has been logged online:
Bug reference: 5056
Logged by: the6campbells
Email address: the6campbe...@gmail.com
PostgreSQL version: 8.4.1
Operating system: windows
Description: SQLDescribeColW for function returning a result set
incorrectly setting sql_nullable
Details:
create table TSET1 (RNUM integer not null, C1 integer, C2 char(3));
create function PRES ( )
returns setof TSET1 as
'
select RNUM, C1, C2 from TSET1;
' LANGUAGE 'sql'
;
in ODBC test sqlPrepare { call pres } then describe the columns. first
column should be SQL_NO_NULLS not NULLABLE.
Describe Column All:
icol, szColName,
*pcbColName, *pfSqlType, *pcbColDef, *pibScale,
*pfNullable
1, rnum, 4, SQL_INTEGER=4, 10, 0, SQL_NULLABLE=1
2, c1, 2, SQL_INTEGER=4, 10, 0, SQL_NULLABLE=1
3, c2, 2, SQL_WCHAR=-8, 3, 0, SQL_NULLABLE=1
I think you may want to try here, for both this and your previous bug report.
pgsql-o...@postgresql.org
http://archives.postgresql.org/pgsql-odbc/
...Robert
--
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] need higher extra_float_digits value (3)
On Wed, Sep 9, 2009 at 6:04 PM, Tom Lanet...@sss.pgh.pa.us wrote: Keh-Cheng Chu kehch...@solar2.stanford.edu writes: While 17 decimal digits are sufficient to guarantee the complete recovery of all 64-bit double values, some 32-bit reals actually require NINE significant figures. Hm, annoying. Seems like we could do one of two things: 1. Increase the max extra_float_digits value to 3 and have pg_dump use that. 2. Split extra_float_digits into two settings so that float4 and float8 can use different settings. Offhand the only argument I can see for #2 is that #1 might bloat dump files unnecessarily --- but it's not likely to be significant on a percentage basis. We'd also need to check the code to be sure it's leaving room for the extra digit in all cases, though I doubt there's really any problem. (2) seems like overkill to me, FWIW. ...Robert -- 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 #5034: plperlu problem with gethostbyname
On Sep 5, 2009, at 6:52 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Thu, Sep 3, 2009 at 5:21 PM, Diego de Limadiego_de_l...@hotmail.com wrote: Using Fedora 10 default rpm packages, all updated last month via yum. I can't reproduce this on a clean build of 8.3.7 or on a clean build of CVS HEAD, both against perl 5.10.0, so I don't think this is a PostgreSQL bug. I'm guessing you have a bug in your code someplace. Here's the test case I used. create or replace function test() returns varchar as $$use Data::Dumper; Dumper(gethostbyname(www.google.com));$$ language plperlu; select test(); Don't have Fedora 10 installed anymore, but the F-11 packages should be equivalent, and on F-11 I get this: test - $VAR1 = 'www.l.google.com'; $VAR2 = 'www.google.com'; $VAR3 = 2; $VAR4 = 4; $VAR5 = 'J}'; $VAR6 = 'J}c'; $VAR7 = 'J}g'; $VAR8 = 'J}h'; $VAR9 = 'J}i'; $VAR10 = 'J}j'; (1 row) I don't know enough about either gethostbyname or Data::Dumper to figure out if this is sane or not. I think so. It's certainly an array rather than just the scalar 1, as the OP alleged we were producing. ...Robert -- 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 #5028: CASE returns ELSE value always when type is char
On Fri, Sep 4, 2009 at 11:15 AM, Tom Lanet...@sss.pgh.pa.us wrote: I certainly don't want to have char emulate the misbegotten decision to have explicit and implicit coercions behave differently. So it looks to me like the argument to make char work like char(1) doesn't actually help us much to decide if an error should be thrown here or not. On the whole, throwing an error seems better from a usability perspective. I like errors. ...Robert -- 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 #5028: CASE returns ELSE value always when type is char
On Fri, Sep 4, 2009 at 11:59 AM, Kevin Grittnerkevin.gritt...@wicourts.gov wrote: Tom Lane t...@sss.pgh.pa.us wrote: I certainly don't want to have char emulate the misbegotten decision to have explicit and implicit coercions behave differently. So it looks to me like the argument to make char work like char(1) doesn't actually help us much to decide if an error should be thrown here or not. On the whole, throwing an error seems better from a usability perspective. I feel that the behavior of char in at least this case should match char(1) (or just plain char): test=# select case when true then 'xxx' else 'a'::char end from t; case -- x (1 row) test=# select case when true then 'xxx' else 'a'::char(1) end from t; case -- xxx (1 row) test=# select case when true then 'xxx' else 'a'::char end from t; case -- xxx (1 row) Much as the reason for the behavior of char may seem clear when inside the code looking out, it is astonishing for someone writing application code. -Kevin Yeah, I agree. That's really confusing. ...Robert -- 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 #5034: plperlu problem with gethostbyname
On Thu, Sep 3, 2009 at 5:21 PM, Diego de Limadiego_de_l...@hotmail.com wrote: The following bug has been logged online: Bug reference: 5034 Logged by: Diego de Lima Email address: diego_de_l...@hotmail.com PostgreSQL version: 8.3.7 Operating system: Linux Fedora 10 Description: plperlu problem with gethostbyname Details: The gethostbyname Perl internal function doesn't work properly on 8.3.7, returning 1 instead of the desired data array. On Postgres 8.2.x it works perfectly. Using Perl v5.10.0. Using Fedora 10 default rpm packages, all updated last month via yum. I can't reproduce this on a clean build of 8.3.7 or on a clean build of CVS HEAD, both against perl 5.10.0, so I don't think this is a PostgreSQL bug. I'm guessing you have a bug in your code someplace. Here's the test case I used. create or replace function test() returns varchar as $$use Data::Dumper; Dumper(gethostbyname(www.google.com));$$ language plperlu; select test(); ...Robert -- 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 #5010: perl iconv function returns ? character
On Tue, Aug 25, 2009 at 8:15 AM, Lampalamp...@gmail.com wrote:
The following bug has been logged online:
Bug reference: 5010
Logged by: Lampa
Email address: lamp...@gmail.com
PostgreSQL version: 8.4.0
Operating system: Debian testing/unstable
Description: perl iconv function returns ? character
Details:
See the difference (example is the best explanation):
psql -U postgres -p 5433
psql (8.4.0, server 8.3.7)
WARNING: psql version 8.4, server version 8.3.
Some psql features might not work.
Type help for help.
postgres=# select my_ascii2('Bockaničová');
my_ascii2
-
Bockanicova
(1 row)
psql -U postgres -p 5432
psql (8.4.0)
Type help for help.
postgres=# select my_ascii2('Bockaničová');
my_ascii2
-
Bockani?ov?
(1 row)
function my_ascii2 is defined:
CREATE FUNCTION my_ascii2(text) RETURNS text AS $$ use strict; use
Text::Iconv; my $conv = Text::Iconv-new(UTF8, ASCII//TRANSLIT); return
$conv-convert($_[0]); $$ LANGUAGE plperlu;
8.3.x version works perfectly, 8.4.0 problem
I can't reproduce this on 8.4.0 or CVS HEAD. I think that whatever
problem you have here is not a PostgreSQL bug.
in more complicated queries (joins, conditions) after my_ascii2 function
query are returned incorect count of rows
This may be related to whatever your other problem is.
...Robert
--
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 #5032: unexpected syntax error for plpgsql function returns table
On Sep 2, 2009, at 11:27 PM, Pavel Stehule pavel.steh...@gmail.com wrote: Hello it's not bug - PostgreSQL doesn't support parameter placeholder on this position. Use dynamic query instead - plpgsql statement EXECUTE. It may not be a bug exactly, but it sure isn't a feature. ...Robert -- 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 #5027: SQL query error?
On Tue, Sep 1, 2009 at 9:51 AM, Dmitrymas...@hsdesign.ru wrote:
The following bug has been logged online:
Bug reference: 5027
Logged by: Dmitry
Email address: mas...@hsdesign.ru
PostgreSQL version: 8.3.5
Operating system: ALT Linux
Description: SQL query error?
Details:
Hello,
I try to make user rating by this query:
BEGIN;
ALTER SEQUENCE service.rate_seq RESTART 1;
UPDATE service.user u
SET rate = sr.rate
FROM (
SELECT user_id, nextval('service.rate_seq') as rate
FROM
(
SELECT user_id, score FROM service.user
ORDER BY score DESC
) a
) sr
WHERE u.user_id = sr.user_id;
END;
all work fine, but if while this query is executing another process do
UPDATE service.user SET score=score+1 i get wrong sequence value; for
example
if user count = 55000 i can get 512321 in sequence ;(
why? query error?
Because sequences are non-transactional. See the description of
nextval(), here:
http://www.postgresql.org/docs/current/interactive/functions-sequence.html
...Robert
--
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 #5028: CASE returns ELSE value always when type ischar
On Wed, Sep 2, 2009 at 11:55 AM, Sam Masons...@samason.me.uk wrote: In fact it doesn't seem to want to play ball at all. Even given the apparently unambiguous: SELECT 1+add(1,2); or SELECT 'hi'||add(1,2); It doesn't get anywhere. No need for text 'hi' in the second one because || isn't defined for values of integer type. Right. This is exactly the sort of thing that languages with real type inference have no problem handling. Of course, ML for example doesn't allow overloading precisely because (AIUI) it makes type inference difficult. It would be awesome if we could make this work though. ...Robert -- 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 #5028: CASE returns ELSE value always when type ischar
On Wed, Sep 2, 2009 at 3:34 PM, Sam Masons...@samason.me.uk wrote: On Wed, Sep 02, 2009 at 12:54:03PM -0500, Kevin Grittner wrote: Sam Mason s...@samason.me.uk wrote: If we did follow Kevin's request directly, should we also be specifying the type of NULL? I don't *think* the SQL standard requires that, and barring that I don't see any compelling reason to type NULL. I've just realized that either I'm missing your point entirely (it's happened before :) or this ignores the point entirely. PG wants to assign types to every expression, whether this expression will evaluate to a NULL value at run-time or not is immaterial in this regard. I think SQL wants to do the same, but I don't have as much conviction as Tom here. Once we're ascribing types to expressions then whether it happens to contain the literal 1, 'txt' or NULL we're committed to giving it some type---the only question is which one. We thus need to type expressions consisting of just NULL constants. A fun puzzle to base any inductive solution on is what type to ascribe to the following: CREATE VIEW v (c) AS SELECT NULL; 'a of course. ...Robert -- 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 #5013: Error in psqlodbc configuration
On Wed, Aug 26, 2009 at 5:55 AM, Isharaishara...@gmail.com wrote: The following bug has been logged online: Bug reference: 5013 Logged by: Ishara Email address: ishara...@gmail.com PostgreSQL version: 8.4 Operating system: Solaris x86 Description: Error in psqlodbc configuration Details: Hi, I used ./configure --with-odbc --enable-pthreads and try to configure psqlodbc in solaris x86. But it exits with an error, .. .. .. checking whether time.h and sys/time.h may both be included... yes checking for long... yes checking size of long... configure: error: cannot compute sizeof (long) See `config.log' for more details. bash-3.00# Pls give me a solution to resolve this. I would suggest that you start by following the directions given in the error message: See `config.log' for more details. If you can't figure it out yourself, you could try posting the contents of config.log and see if anyone else can help. You might also want to redirect your question to pgsql-general. This mailing list is for bugs, and at this point there's no evidence that this is a bug rather than, say, a problem with your system. ...Robert -- 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 #5003: setup error
On Fri, Aug 21, 2009 at 9:35 AM, Pramodpramodchoudhar...@yahoo.com wrote: The following bug has been logged online: Bug reference: 5003 Logged by: Pramod Email address: pramodchoudhar...@yahoo.com PostgreSQL version: 8.4.0-1 Operating system: Windows XP Description: setup error Details: setup error showing message: An error occured while executing microsoft VC++ runtime please send me the solution to this problem There is not nearly enough detail here to guess what happened... ...Robert -- 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 #5019: Nao funciona
On Thu, Aug 27, 2009 at 12:49 PM, Eduardoedua...@vip10.com.br wrote: The following bug has been logged online: Bug reference: 5019 Logged by: Eduardo Email address: edua...@vip10.com.br PostgreSQL version: 8.3 Operating system: Vista 64 bits Description: Nao funciona Details: Utilizava a versao do Vista 32 bits e o Post gres rodava normalmente. Comprei um PC novo e ele veio com o Windons Vista 64 bits, e este programa nao roda mais. O que faço para resolver meu problema. Obrigado. Habla Ud. ingles? This is an English mailing list. I think you also need to provide a bit more detail about what does not work. When you try to start the program, what happens? Is there anything in the error log? Para obtener ayuda en espan~ol, tal vez puede Ud. tratar pgsql-es-ay...@postgresql.org. Creo que no tenemos una list de correo en Portugue's. ...Robert -- 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 #5019: Nao funciona
2009/8/27 Alvaro Herrera alvhe...@commandprompt.com: Robert Haas escribió: Para obtener ayuda en espan~ol, tal vez puede Ud. tratar pgsql-es-ay...@postgresql.org. Creo que no tenemos una list de correo en Portugue's. It lives in another list server: https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Should there be a pointer on http://www.postgresql.org/community/lists/ ? ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
