Re: [BUGS] BUG #5687: RADIUS Authentication issues
Alan T DeKok wrote: > the hard-code 10 could be USECS_PER_SEC. To save others the time of checking, it's actually 100 in the patch. -Kevin -- 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] Facing problems with postgres 9.0.0
Sekhar chakka wrote: > We have installed Postgres 9.0.0 on ubuntu 10.04 LTS 64 bit > machine. It was working untill you restart the server. Once the > server is rebooted the database is not starting Is there a service configured to start on reboot which runs it? > "psql: could not connect to server: No such file or directory > Is the server running locally and accepting > connections on Unix domain socket "/tmp/.s.PGSQL.5432"?" Is the server running? (Check ps output.) Can you start it manually? If not, what's in the log? -Kevin -- 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] Mapping Hibernate boolean to smallint(Postgresql)
[Moving the discussion to the PostgreSQL JDBC list, with a blind copy to bugs. This doesn't sound to me like a bug, per se, but an extension to the JDBC driver which may be a convenience to some users. We're more likely to get the attention of the right group of people on the JDBC list.] stagirus wrote: > I guess it would be set/getBoolean methods, right? Maybe. I'd rather not guess at what it is you need though. > If you need, I will get the exception report from my developer. Please do. That would allow us to make sure that if we try to help, we're working on the right part of the code. It's so much harder to hit a target when shooting in the dark. ;-) -Kevin -- 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] Mapping Hibernate boolean to smallint(Postgresql)
stagirus wrote: > JDBC driver does not convert boolean value (false/true) to > integers (0/1). Can you mention which methods of which classes you would expect to do this? -Kevin -- 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 in sorting strings
Edoardo Serra wrote: > SELECT * FROM dummy ORDER BY string ASC; > string > > 100% > 10.1 > (2 rows) > > I would expect the order of the results to be '100%', '10.1'. > Moreover, if I use the following dataset, I get the correct sorting > > SELECT string, ascii(substr(string, 3, 1)) FROM dummy ORDER BY > string ASC; > string | ascii > +--- > 10. | 46 > 100 | 48 You left out the most important piece of information -- what collation have you configured? Many common collations ignore special characters (except perhaps as tie-breakers), so your examples sort based on: '100' '101' versus '10' '100' Both examples look right if you are using such a collation. -Kevin -- 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 #5646: missing chunk number 0 for toast
"missing chunk number" wrote: > when i run my table in editor i faced this below error. > Ex: select * from ad_role > > ERROR: missing chunk number 0 for toast value 525559 in > pg_toast_325765 > > ** Error ** > > ERROR: missing chunk number 0 for toast value 525559 in > pg_toast_325765 > SQL state: XX000 > > > How can i solve this error.Can u guide me. This is database corruption and extremely unlikely to be a bug in the current maintenance release of 8.3. Please read the following page and post with more information to the pgsql-general list: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems Your first step, though, should be to stop the PostgreSQL service and make a complete copy of the data directory and all its subdirectories, and plan on keeping that until at least a few weeks after the issue is resolved. -Kevin -- 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] issue about information_schema REFERENTIAL_CONSTRAINTS
Tom Lane wrote: > Yeah, exactly. I think that the current tradeoff is just fine. > If you want SQL-standard behavior, pick SQL-standard constraint > names, and there you are. I see that as the crux if it -- the current implementation *allows* standard-conforming behavior, even though it doesn't *enforce* conforming naming. The proposed alternative does not allow standard-conforming behavior. If you're going to use something which is PostgreSQL-specific, you may as well write your own views or use the "native" tables and views directly. -Kevin -- 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] How to restore the database on a failed start database server service
>LINO-ANTOINE PATY GISIBU wrote: > Hi! I am a user of one of your product; The Postgresql database > server in his version 8.3. 8.3.what? Obtained how? > No long time, after an electricity power interruption, I could not > start my database server Which means you probably either have hardware damage or are running with configuration options which don't guarantee database integrity. Does your postgresql.conf file have fsync = off or full_page_writes = off? > and then I quicky went to check the Windows Logs reports > about the Postgresql 8.3 service, I see that It was not started What messages did you find? > and I tried to start it manually without success. What messages did you get? > my final solution is to RESTORE the datas Hopefully you saved the original database somewhere before attempting to restore. What form of backup were you using? How did you attempt to restore? > there are so important for my devil organisation I can not do > anything else but taking the database out of this hell. I have absolutely no idea what that means. > Here I am with my SOS, How can i restore the database from the > system which does not even start I mean the server can not start > no way to restore datas, help me please. Is there any way to > restore the database even if the server can not start? Nobody can begin to give recovery advice without knowing what you have available to use in the recovery. Do you have an image of the database in the state it was in following the power failure? Do you have any backups? If so, what kind? (pg_dump, pg_dumpall, PITR, file-system copy of the data directory while PostgreSQL was stopped, etc.) More detail is very valuable -- see this page for ideas of what else to include: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems By the way, this doesn't sound like a PostgreSQL bug; it would be better to post such things on pgsql-admin or pgsql-general. -Kevin -- 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 #5613: cannot delete
Scott Wheeler wrote: > Can you tell me what the pg_stat_tmp file is used for? It's not a file; it's a subdirectory. The statistics information is periodically written to a file within that subdirectory when PostgreSQL is running. I concur with prior advice -- make sure you don't have a postgres process running, and the rest is all Windows skills -- there should be nothing special caused by PostgreSQL. -Kevin -- 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 #5607: memmory leak in ecpg
[moving discussion to -hackers] Michael Meskes wrote: > "Kevin Grittner" schrieb: >>"Marcelo Mas" wrote: >> >>> Valgrind reports memmory leak when getting decimal data. >> >>I wonder how much overlap there is between this and the patch for >>fixing ECPG memory leaks offered by Zoltán Böszörményi three days >>ago. >>http://archives.postgresql.org/pgsql-hackers/2010-08/msg00115.php > I guess the described problems are identical. Feel free to apply > the memleal patch. Is someone dealing with this? Should this be on the "PostgreSQL 9.0 Open Items" Wiki page? -Kevin -- 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 #5612: Database Integrity
"Ramachandran S" wrote: > I have observed that if a table exceeds size (default > installation) 1 GB. The table when it exceeds 1 GB a file is > created say 1811(table) with 1811.1 and further records added are > insertted into this file. My Question if I remove the file 1811.1 > say still database is starting up? I will never know that such a > file existed nad remved and data of 1811 is also availble? > How can stop the start the database when such situation recur. > pgfsck was available 8.2 I don't see any hint of a PostgreSQL bug here. Since there's not really enough in your post to get very far, please re-post to a more appropriate list. pgsql-general is probably your best bet. I'm not entirely clear on whether you are asking a hypothetical question or whether your database cluster is currently out of commission because you mangled the underlying files. If you're trying to recover from such damage, please post actual details. See this page for suggestions on what to include: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems If this is all hypothetical, my advice is to review the backup documentation and always keep up-to-date backups, and never delete files in the manner you describe. -Kevin -- 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 #5607: memmory leak in ecpg
"Marcelo Mas" wrote: > Valgrind reports memmory leak when getting decimal data. I wonder how much overlap there is between this and the patch for fixing ECPG memory leaks offered by Zoltán Böszörményi three days ago. There was much discussion about the dynamic UPDATE/DELETE WHERE CURRENT OF patch, but I don't remember any discussion of the other patch included in the same post. http://archives.postgresql.org/pgsql-hackers/2010-08/msg00115.php -Kevin -- 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] My computer shut down automatically
wrote: > I tried to uninstall Postgresql. But, "data" folder was denied > to remove. How? And how was it installed in the first place? > When I tried to remove "data" folder in 8.4 folder by force, my > computer shut down and startup automatically. Tried to remove it how? > Can I delete "data" folder? If you uninstalled PostgreSQL, I don't see that it would be PostgreSQL stopping you. In general, PostgreSQL doesn't stop you anyway, beyond having files open when it's running. > (When I open the folder, my computer shut down, too) I've never heard of anything remotely like that. Have you checked the Windows logs? You might also see if anything unusual is showing up on the process list. Before posting again, please read this: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -Kevin -- 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 #5599: Vacuum fails due to index corruption issues
Hitesh Bhambhani wrote: > Could you give an example of what an 'extraordinary circumstance' > would be? Normal vacuums will remove old tuples (versions of rows) which can no longer be seen by any transaction, and make that space available for re-use within the PostgreSQL files. It will not normally give space back to the OS, but that's usually a *good* thing, because normally the space will soon be needed again by PostgreSQL, and it would be less efficient to constantly be giving space back and allocating it again. If you neglect to vacuum aggressively enough, or do a mass UPDATE or DELETE which affects a large percentage of your rows, without anticipating that you will need that space again soon, you might want to do aggressive maintenance to shrink the PostgreSQL files. VACUUM FULL will move tuples around within the table to free up space at the end so that it can be released. But wait -- you probably *still* don't want to use VACUUM FULL, because it is *very* slow and will bloat your indexes, requiring a REINDEX to restore decent performance. CLUSTER will rewrite the table without dead space and will rebuild the indexes -- usually much faster than VACUUM FULL. But CLUSTER needs room for a second copy of the table in order to copy it. If you have a very bloated table which you want to shrink and you don't have room for a second copy of it, *that* is the time to consider VACUUM FULL (usually followed by REINDEX). If you ever find you *do* need to run VACUUM FULL, you probably need to re-evaluate your maintenance procedures to see how you can avoid having to do it again. -Kevin -- 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] string_agg delimiter having no effect with order by
Alex Hunsaker wrote: > On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote: >> If we were a bit earlier in the 9.0 cycle I would suggest that >> this confusion is a sufficient reason to drop the one-argument >> form of string_agg. It's too late now though. > > FWIW I think we can still change it. Isn't this type of issue > part of what beta is for? If we were in RC that would be a > different story I like to think I'm pretty serious about controlling scope creep to prevent a release dragging out, but this one seems like beta testing uncovered a flaw in new code for the release. In my book, that makes it fair game to balance the risk of breaking things by changing it now against the problems we'll have long term if we leave it alone. I'm not sure if that was the basis of saying it was too late, or some other consideration. -Kevin -- 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 #5591: Creating and using databases
"Divyaprakash" wrote: > I am unable to create the databases after the successful > installation of postgresql. please help me as early as possible. We need more information before we can be much help. Please read this and post again on the pgsql-general list. It really doesn't sound like a bug. http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -Kevin -- 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 #5573: How can i add field inbetween in the table while creating
"Vimi" wrote: > How can i add field inbetween in the table while creating This is not a bug; in the future please post such questions to pgsql-general. While the feature you're requesting is likely to appear in a future release, current releases require that you create a new table with the desired structure, copy data from the old table into it, drop or rename the old table, and rename the new table into place. You would probably want to begin a transaction and acquire an exclusive lock on the old table before starting this, and commit after the new table is in its place. On the other hand, in well-written software, the order of the columns in the table should make no difference; you might just want to avoid SELECT * and dodge the whole issue. -Kevin -- 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 #5572: Error Trying to connec from Crystal Reports to Sever PostgreSQL
"Tizziano Perea" wrote: > PostgreSQL version: 8.2.17 > Operating system: CentOS 5.4 > Description:Error Trying to connec from Crystal Reports to > Sever > I,ve been install Crystal Reports 11 in a WinXP machine, and when > i tried to connect to PostgreSQL (CentOS 5.4) the following error > appears: > > La conexion no es posible > Detalles: 08001: Could not connect to the server > Could not connect to remote socket: [Codigo de proveedor de Base > de Datos: 101] > > I edited the pg.hba.conf and postgres.conf files, but the error > persist. In the future it would be better to post such problems to the pgsql-general list, as this doesn't really sound like a bug in PostgreSQL; it sounds like you don't have everything configured correctly. Without seeing the changes you made to the .conf files and knowing how Crystal Reports is trying to connect, it's hard to guess what the problem may be. Please post the contents of the postgresql.conf and pg_hba.conf files with all comments removed. Also, please give any information you can about how Crystal Reports is trying to connect. Also something to consider: did you do the appropriate reload or restart to get PostgreSQL to notice the changes after you edited the .conf files? -Kevin -- 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 #5568: will not install
"Lowell Harris" wrote: > I keep getting an error message: > "An error occured executing the Microsoft VC++ runtime installer" > This computer has MS Visual Studion 2005 and I also went ot > Microsoft and updated the CV++ runtimes. What was the URL of the download you're installing? Exactly what steps did you take to attempt installation? > I found an install string in your support forum Which was? > it tried to install, but I received another error message near the end of hte installation process. Which was? > The program itself won't connect to the local host server. So the server is running? > On and on and on. If you want useful suggestions, a bit more detail is needed. > I'm somewhat disapointed that the Best Database in the World > won';t even install? Well, it installs just fine for most users; so the question is: what's different in your case? You need to give us a lot more detail to be able to determine that. > Any thoughts? http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -Kevin -- 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 #5565: ERROR : syntax error at or near ")"
"john" wrote: > PostgreSQL version: 8.4.1 If you update to the latest 8.4 bug fix release (currently 8.4.4), you'll avoid any bugs which have already been found and fixed. http://www.postgresql.org/support/versioning > when insert using client dataset after post upplyupdates(0) in > delphi i receive this error : > > ERROR : syntax error at or near ")"+postgres Perhaps someone who knows delphi can make something of that, but I'm afraid I'd need more information before I could suggest anything. If you could capture the statement which is generating the syntax error it would help. You might want to read through this page to get other ideas about what you could tell us which would allow us to better help you: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -Kevin -- 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 #5547: not able to connect to postgres through the oracle using Linux ODBC driver for Postgres
"Hemanth" wrote: > role "AIP" does not exist This suggests that you're trying to log in as "AIP", and PostgreSQL is not finding that role. Can you connect to PostgreSQL with the psql command-line utility and run?: \du If so, please show us the results. By the way, in the future please try to pick a more appropriate list, there is nothing in your report to suggest that this is the result of a PostgreSQL bug. See: http://www.postgresql.org/community/lists/ This would probably fit best on pgsql-odbc or pgsql-general. -Kevin -- 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 #5535: Backslash in condition for LIKE statement is not seen
"Jeff Benjamin" wrote: > Seems one cannot use a backslash character in a LIKE condition. By default that has special meaning as an escape character. Try this: select * from test where pattern like E'\\w%' escape '#'; or this: select * from test where pattern like E'w%'; -Kevin -- 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] JDBC: 2 bugs: Getting a smallint array actually gets an integer array and return type of a boolean array is bit.
Saneesh Apte wrote: > the base type of a boolean[] is java.sql.Types.BIT instead or > java.sql.Types.BOOLEAN. At the very least shouldn't these be > aliases for the same type? > > And secondly the returned type from a smallint[] is an Integer[] > instead of a Short[]. Should the objects in the array returned by getArray be typed according to the rules of an individual value returned by getObject? (I couldn't find anything explicit on that, but it seems reasonable.) If that *is* true, the controlling part of the spec is: http://java.sun.com/javase/6/docs/technotes/guides/jdbc/getstart/mapping.html#table3 That maps SQL types TINYINT, SMALLINT, AND INTEGER to Java Integer. It also maps SQL BIT to Java Boolean. The SQL type of BOOLEAN was a latecomer to the SQL spec, and it appears that JDBC hasn't yet added it to the mappings. Do you have a reference to something which indicates that getArray should use a different mapping? Maybe someone will see it differently, but I don't think I see a bug here. Compliance with the spec is not a bug, even if the spec is a bit odd ;-) -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Postgres on AIX5.3 and AIX6.1
Liang Giap Wee wrote: > We are considering using your open source Postgres on AIX5.3 and > AIX6.1. > > May i know if you have a opensource community to help with support > issues should we face problem with during installation? Thanks... Yeah, you'll find that there's an active and responsive user community. It is good to pay attention to the descriptions of the lists, and post to the correct list. It helps to keep things organized and to put the issue in front of the right people. (For example, this is not a bug; it should have been posted to pgsql-general.) You can see the available lists at: http://www.postgresql.org/community/lists/ I hope that helps. -Kevin -- 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 #5509: PostgreSQL fail to show table names containing "
"Fosforo Mann" wrote: > Tried to view the table schema without success, and them only > typing TAB TAB If the table name contains uppercase letters, you need to type the " before trying the TAB. -Kevin -- 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 #5507: missing chunk number 0 for toast value XXXXX in pg_toast_XXXXX
中嶋 信二 wrote: > postgres is duplicated. > Red Hat Cluster Suite watches a process of each service. > PGDATA shares it in strage. > > There is the thing that a wait server started. > A cluster began the change disposal of servers. > Because A cluster judged a state of postgres to be a stop. > > I do not understand why duplex system to refer to same PGDATA was > able to start. > I was able to surely carry out SQL by a psql command in duplex > system. > I did not output log in those days. > Two postgres that PGDATA was shared will have started > why if it was thought that it was caused by double start. > Is there such a precedent? > Does a data file lead to the cause that failed? I'm not sure I totally understand, but it sounds like you had two postmasters running against a single data directory. If so, that could cause all kinds of corruption. It's hard to see how that could happen unless you deleted a PostgreSQL data directory, or at least the postmaster.pid file, while an instance was running. I would start by capturing "ps auxf" output, to be able to understand what postgres processes were running and when they started. Then I would probably make sure they all got stopped. Then I would be seriously looking at restoring from backup, unless this was a development database which could just be recreated from scratch. -Kevin -- 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 #5507: missing chunk number 0 for toast value XXXXX in pg_toast_XXXXX
"Shinji Nakajima" wrote: > Error message called "missing chunk number" occurred when I did > select of the specific column of the specific table. > I delete a record, and the system restores, but prime cause is > unknown. Will this be a bug of the databases? Errors like this are usually caused by hardware problems. I think the second-most common cause is running in a configuration with fsync = off or full_page_writes = off, and suffering a power outage or OS crash. I would recommend that you check your configuration for these unsafe settings and schedule a check of your hardware and drivers. -Kevin -- 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 #5499: SQL syntax bug
"Curtis Stecke" wrote:
> Inserting text that starts with or ends with a dollar sign ($) is
> impossible. Documentation is not clear on how to do this as well.
Works for me. Care to give an example of your problem?
test=# create table t1 (c1 text);
CREATE TABLE
test=# insert into t1 values ('$sometext');
INSERT 0 1
test=# insert into t1 values ('sometext$');
INSERT 0 1
test=# insert into t1 values ('$sometext$');
INSERT 0 1
test=# select * from t1;
c1
$sometext
sometext$
$sometext$
(3 rows)
-Kevin
--
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 #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Hartmut Goebel wrote: > re. 1): While this may be true for many applications it is using > hand-crafted SQL statements, it is plain wrong for all applications > using some abstraction layer. These layers need to quote column > names anyway and the application does not need to be changed here > at all. I have a feeling that many here don't understand how ubiquitous such frameworks are. Our programmers have no way to get a statement to the database from within the application *without* all identifiers being quoted. On the other hand, my conversion software has always been a command line with pg_dump piped to psql. (We are making our first test of Bruce's new techniques this week, though.) -Kevin -- 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 #5495: RI/FK on self and inherited table
"Martin Edlman" wrote: > ERROR: insert or update on table "device" violates foreign key > constraint "device_parent_id_fkey" > DETAIL: Key (parent_id)=(19947) is not present in table "device". > > But the record is there, it was inserted into net.computer so it's > selectable from net.device and from net.computer. This is not a bug, but a known limitation. Bring up this page and look for the places it mentions "foreign key": http://www.postgresql.org/docs/8.4/interactive/ddl-inherit.html -Kevin -- 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] Invalid YAML output from EXPLAIN
Dean Rasheed wrote:
> So that just leaves this sort of thing:
>
> explain (format yaml) select * from foo as "123";
What about other quoted identifiers? If I recall correctly, a
quoted identifier can contain *any* characters (although a quote
must be represented as two adjacent quotes).
test=# create schema "0";
CREATE SCHEMA
test=# create table "0"."123" ("456" int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"123_pkey" for table "123"
CREATE TABLE
test=# explain (format yaml) select * from "0"."123" where "456" =
'789';
QUERY PLAN
---
- Plan: +
Node Type: Index Scan+
Scan Direction: Forward +
Index Name: "\"123_pkey\"" +
Relation Name: 123 +
Alias: 123 +
Startup Cost: 0.00 +
Total Cost: 8.27 +
Plan Rows: 1 +
Plan Width: 4+
Index Cond: "(\"456\" = 789)"
(1 row)
Also, the trailing spaces in this format (stripped from this email
to avoid odd spacing) are more than a little annoying.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: BUG #5490: Using distinct for select list causes insert of timestamp string literal to fail
>Farid Zidan wrote: > but when it gets to use the resultset of the subquery in the > insert it "forgets" how to convert '2010-04-30 00:00:00' to > timestamp value Not really. In versions prior to 8.3 it did automagically convert like that. PostgreSQL has some pretty fancy features involving custom data types where this magic caused problems, so a deliberate decision was taken to no longer provide automatic casts from text to other data types. > (but forgets only when 'distinct' is used in the subquery!) That is because (as I tried to explain earlier, but apparently didn't do a good job of communicating), an unadorned literal in single quotes is *not* taken to be a character string in PostgreSQL. Its type is held as "unknown" until it is forced to be resolved in some operation. This allows easier coding of custom data types, but does create a few deviations from standard behavior in corner cases, and breaks from the non-standard "conventional" behavior of many other databases. Because of this design choice, for example, the FAA can more easily write the code they use to map their runways and other airport facilities. The cost is that in situations such as you describe, you need to force the type before it is used in the comparisons necessary to determine a distinct value. The only way to get the behavior you want without breaking a great many useful cases, would be to determine where the result was going to be later used, and use that information to force the type to something other than text (the default, when no other information is available). That would be a *major* and destabilizing change. For those reasons, the chance of getting *anybody* here to consider this a bug are close to nil. The choice to more conveniently handle advanced cases at the expense of occasionally needing to specify a type is unlikely to be reversed, to put it mildly. I can't help but wonder why you resist using the standard syntax. The reason the standard exists is to help those trying to write portable code, so they don't have to count on the vagaries of "parallel evolution." -Kevin -- 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 #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
David Fetter wrote: > It seems like something that's doable by pg_dump as a "default > off" option. TODO for 9.1? Sounds good to me. -Kevin -- 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 #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Hartmut Goebel wrote: > The application already quotes all column names :-) It's using a > generic framework which does not (and must not) rely on column > names being non-keywords. Same here. I suspect that this is much more commonn than many PostgreSQL developers realize; and I think it makes a reasonable case for at least an *option* to quote all identifiers emitted by pg_dump. -Kevin -- 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 #5490: Using distinct for select list causes insert of timestamp string literal to fail
>Farid Zidan wrote: > can be eliminated by appropriately handling the distinct keyword > and does not have to occur. Based on previous discussions around our approaching data types, I don't think any of the regular PostgreSQL developers are likely to agree with you; but if you see a way to make it work, feel free to submit a patch. See this page for the process: http://wiki.postgresql.org/wiki/Submitting_a_Patch > The ISO-datetime string literal format I am using the most > general/standard for datetime/timestamp and is not the issue here. The format in your string literal is the portable one; however, a timestamp literal requires the TIMESTAMP keyword ahead of the string literal, which you have chosen to omit. Did you try the query with a proper timestamp literal, as I suggested, against all these databases? If using standard syntax works, why not use it? > The 'distinct' keyword is causing the error. No, non-standard syntax is causing the error in the case of DISTINCT, because our extension to the standard does not cover that case, even though it covers the other. There are good reasons for that, which you'll probably discover in short order if you work on a patch for the issue. -Kevin -- 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 #5490: Using distinct for select list causes insert of timestamp string literal to fail
>Farid Zidan wrote: >> If we were strictly complying with the SQL standard, > Considering the statement works in all the 9 DBMS systems+ that I > have tested so far as mentioned above, I would say PostgreSQL is > not compliant with SQL standard in this regard. The SQL standard is a document published by the International Standards Organization (ISO) and also adopted by the American National Standards Institute (ANSI). Those documents don't require a query in either of the forms you presented to work. Because of the convenience factor, most database products have non-standard extensions to omit type specification in some places. PostgreSQL's extensions are oriented more toward user-installable data types (such as geometric shapes or global coordinates), so the particulars of our non-standard extensions differ so that use of those features is as easy as practicable. That does result in some non-standard extensions which work in other products not working in PostgreSQL. I think you'll find that the syntax I suggested (using the standard timestamp literal instead of a bare character string literal) will work in all of the databases you mentioned; if you want portable code, it is best to follow the standard rather than some inferred popular convention. I hope this helps. -Kevin -- 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 #5490: Using distinct for select list causes insert of timestamp string literal to fail
"Farid Zidan" wrote: > insert into test_insert > (col1, col2) > select distinct > 'b', > '2010-04-30 00:00:00' > > > ERROR: column "col2" is of type timestamp without time zone but > expression is of type text > LINE 16: '2010-04-30 00:00:00' > ^ > HINT: You will need to rewrite or cast the expression. Try using a timestamp literal instead of a bare literal: insert into test_insert (col1, col2) select distinct 'b', timestamp '2010-04-30 00:00:00' This is actually working as intended in all the cases you showed, so it isn't a bug. If we were strictly complying with the SQL standard, your first example would also fail, but we are more lenient than the standard where we can be, to allow an unadorned literal to be an UNKNOWN type until something causes it to be resolved, to allow people to omit the type decoration in many cases. To determine that something is a distinct value, you have to determine a type for it (otherwise you won't know if '2010-04-30 00:00:00' is the same as '2010-04-30 00:00:00.0', for example), so if you don't tell it otherwise, it will assume text -- leading to the behavior you saw. -Kevin -- 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 #5443: Undetected deadlock situation
Claudio Freire wrote: > On Thu, 2010-06-03 at 13:42 -0400, Tom Lane wrote: >> Claudio Freire writes: >> > What I did do is analyze server load during the events, and as >> > I suspected, disk activity during the "deadlocks" seems to >> > suggest a vacuuming taking place. Although there was no >> > autovacuum entry in pg_stat_activity every time I checked, disk >> > activity precisely matches the case when autovacuum decides to >> > vacuum a big table. >> >> [ shrug... ] If autovacuum isn't shown in pg_stat_activity then >> it's pretty hard to credit that there was an autovacuum going >> on. Moreover, if there *was* an undetected deadlock that >> autovacuum was somehow involved in, then the autovacuum would be >> blocked too so it's hardly possible that you'd miss seeing it in >> pg_stat_activity. > > I know. However, I seem to recall that HOT did a sort-of vacuuming > of full pages, hoping to make space and not resort to regular > updates. Now that wouldn't show up in pg_stat_activity, would it? It would show up as part of whatever DML statement initiated the cleanup. It also wouldn't generally look a whole lot like a table-level vacuum. Other prime suspects would be checkpoint activity (you might want to turn on checkpoint logging and see if those match up to the events) and hint-bit rewrites (which can cause disk writes the first time tuples are read after they are committed). Based on what I've heard so far, I wouldn't entirely rule out some sort of bloat being a factor, either. -Kevin -- 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 #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
Hartmut Goebel wrote: > If upgraded the rpm-packages from 8.3 to 8.4. Then postgres failed > starting (something like "Database version mismatch"). You need to be running the old server using 8.3 software and while using pg_dump from 8.4 software. Does your packager provide some way to install the new version at a different location? If not, is there a separate machine on which you could install 8.4? -Kevin -- 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 #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
>Hartmut Goebel wrote: > I dumped with the executable form 8.3. That's not expected to work for an upgrade to 8.4. > 8.4 did not allow accessing the 8.3 database What do you mean? (What did you try and what happened?) -Kevin -- 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 #5488: pg_dump does not quote column names -> pg_restore may fail when upgrading
"Hartmut Goebel" wrote: > Description:pg_dump does not quote column names -> > pg_restore may fail when upgrading > If a 8.3 table contains a column named "window", the dump can not > be restored into a 8.4 database. Reasons: a) "window" is a new > keyword in 8.4 b) pg_dump does not quote column names. Note that the documentation recommends always running pg_dump using the executable from the target version, not the source version. Are you using the pg_dump executable from 8.4? -Kevin -- 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] canceling statement due to user request
"Spangler, Todd" wrote: > canceling statement due to user request > I cannot seem to fix. Your application is canceling queries, probably because they're not completing as quickly as it wants them to; that's not a PostgreSQL bug. You should probably gather a bit more information and post to the pgsql-performance list, to see what you can do to improve the query speed. > I have read that this may have something to do with the Autovacuum > feature. Probably not -- at least not directly. It's possible that you aren't vacuuming aggressively enough, and therefore suffer poor performance from bloat, but at this point, that's just conjecture. > It seems the errors do not happen every time. What pattern is there? Do they come in clusters? Is it particular queries? Is it particular search arguments for a query? > If this is the Autovacuum feature, is there a way that I can > disable this feature and then re-enable it when I am done with the > creation of my report? That would probably be counter-productive, although setting autovacuum cost limits to pace the vacuums might possibly be useful. > Also, when we receive these errors, it does not save any > information to the text file like it normally would without the > error message, so we do not get the report we need when these > errors occur. What text file is that? With our configuration, we *do* see statement text for these in the PostgreSQL log files. > Another thought would be for us to allow the Autovacuum to be > turned on only at certain times. That would be pretty risky, and probably counter-productive. > I have read that these messages are by design I'm curious what you read. Can you share a URL? > I need an easy to use workaround that will allow the reports to > work. These reports are very important to the company. Please read these pages and post again to a different list with more detail: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems http://wiki.postgresql.org/wiki/SlowQueryQuestions In particular, since this could be related to checkpoints, it is important to have a good description of your hardware, especially your disk storage system, and all settings in your postgresql.conf file (excluding all comments). -Kevin -- 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 #5484: sum() bug
Robert Haas wrote: > On Tue, Jun 1, 2010 at 9:24 AM, viras wrote: >> What type of the data is better for using? Numbers up to 10 >> and accuracy of 2 fractional signs. > > numeric is a good choice to avoid loss of precision, but can be a > bit slower. > > You could also try float8. Yeah, as long as you remember that this is an *approximate* data type. If you really mean that you're satisfied with an *accuracy* of two fractional digits for a number up to 10, you are OK. But realize that means that 1.01 would actually be 1.0100088817841970012523233890533447265625 and that 10.01 would actually be 10.0094761310517787933349609375 -- accurate to far more than two decimal digits, but not *exact*. If you want exact values based on decimal fractions, you should use numeric. -Kevin -- 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 #5477: CREATE DOMAIN NOT NULL constraints not always enforced for INSERT with subquery
Tom Lane wrote: < NOT NULL constraints at the domain level suck. Don't use 'em. +1 As someone who uses domains very heavily, I can attest that the semantics of that are very weak. Whether a domain is nullable depends almost entirely on the context of its use, which you can't (and shouldn't try to) anticipate on its declaration. -Kevin -- 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 #5474: Installation
"Nelson da Silva" wrote: > PostgreSQL version: 8.0.2.1 > Operating system: Windows XP That's not a supported combination: http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy You should look at upgrading as soon as practicable. > An error ocurred executing the Microsoft VC++ runtime installer We would need a lot more information than that to provide useful advice. Please read this page: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -Kevin -- 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 #5448: psql \set does not terminate if variable is referenced recursively
Tom Lane wrote: > I think we need to add an explicit recursion test and suppress > further expansion of the variable when we see it > We can definitely print a message Sounds perfect to me. -Kevin -- 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 #5448: psql \set does not terminate if variable is referenced recursively
Tom Lane wrote: > We could print a message and treat the inner > expansion as empty --- is that good enough? If there's any way to throw an error, that seems better. I can imagine someone getting confused by silent failure here. On the other hand, since this probably doesn't happen very often, maybe it's not worth the effort. I could even see an argument for just testing for Ctrl+C before each expansion and otherwise leaving it as is. -Kevin -- 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 #5448: psql \set does not terminate if variable is referenced recursively
"Francis" wrote: > psql \set does not terminate if a variable is referenced > recursively. For example, the following will hang the psql client > in a nasty way: > > db=# \set n 1 > db=# \set n (:n + 1) It seem to me that the above doesn't hang the psql client, but a subsequent reference to :n does. It doesn't have to be a direct self-reference, either; any circular reference seems to do it. It doesn't respond to Ctrl+C during this recursion. pgbench=# \set n 1 pgbench=# \set x (:n+1) pgbench=# select :x; ?column? -- 2 (1 row) pgbench=# \set n 5 pgbench=# select :x; ?column? -- 6 (1 row) pgbench=# \set n (:x+1) pgbench=# select :x; [CAUTION: psql sucked CPU time and ate RAM until I killed it] -Kevin -- 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 #5443: Undetected deadlock situation
Claudio Freire wrote: > I know it doesn't look like a deadlock from where you're standing, > but it does so from where I am. It's possible that you're filtering out the information which would be most useful to diagnosing the problem. Next time it happens, please send the entire output from pg_locks and pg_stat_activity (preferably as attachments to avoid wrapping issues), along with the information listed under "Things you need to mention" on this page: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -Kevin -- 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 #5443: Undetected deadlock situation
Peter Eisentraut wrote: > This is not a deadlock. Agreed. > It's just two locks on the same table Not as I read it. > (and maybe a bit more readable formatting). Eliminating null columns and mangling column headers for length, I get this: >> locktype| tranid | virtualx | pid | mode | gr >> transactionid | 39773877 | 63/15761 | 11157 | ShareLock | f >> transactionid | 39773877 | 4/10902 | 6421 | ExclusiveLock | t So it looks like two locks on the same transaction ID by different transactions. How does that happen? -Kevin -- 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 #5441: Why Not?????
"sibal" wrote: > Description:Why Not? > Why Not Download PG8.4? It's not clear what bug you think you've seen. If the problem is that you're having trouble downloading a file, we'd need a lot more information (like the URL from which you're trying to download) in order to offer any advice. Please review this page: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -Kevin -- 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 with Tsearch and tsvector
"Kevin Grittner" wrote:
> I'll read this RFC closely and follow up later today.
For anyone not clear on what a URI is compared to a URL, every URL
is also a URI (but not the other way around):
A URI can be further classified as a locator, a name, or both.
The term "Uniform Resource Locator" (URL) refers to the subset of
URIs that, in addition to identifying a resource, provide a means
of locating the resource by describing its primary access
mechanism (e.g., its network "location").
So rules for URIs apply to URLs.
Regarding allowed characters, the relevant portions seem to be:
The URI syntax has been designed with global transcription as one
of its main considerations. A URI is a sequence of characters
from a very limited set: the letters of the basic Latin alphabet,
digits, and a few special characters.
The generic syntax uses the slash ("/"), question mark ("?"), and
number sign ("#") characters to delimit components that are
significant to the generic parser's hierarchical interpretation of
an identifier.
A URI is composed from a limited set of characters consisting of
digits, letters, and a few graphic symbols. A reserved subset of
those characters may be used to delimit syntax components within a
URI while the remaining characters, including both the unreserved
set and those reserved characters not acting as delimiters, define
each component's identifying data.
A percent-encoding mechanism is used to represent a data octet in
a component when that octet's corresponding character is outside
the allowed set or is being used as a delimiter of, or within, the
component. A percent-encoded octet is encoded as a character
triplet, consisting of the percent character "%" followed by the
two hexadecimal digits representing that octet's numeric value.
For example, "%20" is the percent-encoding for the binary octet
"0010" (ABNF: %x20), which in US-ASCII corresponds to the
space character (SP). Section 2.4 describes when percent-encoding
and decoding is applied.
pct-encoded = "%" HEXDIG HEXDIG
The uppercase hexadecimal digits 'A' through 'F' are equivalent to
the lowercase digits 'a' through 'f', respectively. If two URIs
differ only in the case of hexadecimal digits used in percent-
encoded octets, they are equivalent. For consistency, URI
producers and normalizers should use uppercase hexadecimal digits
for all percent-encodings.
reserved= gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
I think that we should accept all the above characters (reserved and
unreserved) and the percent character (since it is the escape
character) as part of a URL.
Certainly *not* back-patchable.
I don't know whether we should try to extract components of the URL,
but if we do, perhaps we should also adopt the standard names for
the components:
The generic URI syntax consists of a hierarchical sequence of
components referred to as the scheme, authority, path, query, and
fragment.
URI= scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
The scheme and path components are required, though the path may
be empty (no characters). When authority is present, the path
must either be empty or begin with a slash ("/") character. When
authority is not present, the path cannot begin with two slash
characters ("//"). These restrictions result in five different
ABNF rules for a path (Section 3.3), only one of which will match
any given URI reference.
The following are two example URIs and their component parts:
foo://example.com:8042/over/there?name=ferret#nose
\_/ \__/\_/ \_/ \__/
| ||||
scheme authority pathquery fragment
| _|__
/ \ /\
urn:example:animal:ferret:nose
I'm not really sure of the source for names we're now using.
Of course, the bigger the changes, the less they sound like material
for a quick, 11th hour 9.0 patch.
-Kevin
--
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 with Tsearch and tsvector
Tom Lane wrote: > "Kevin Grittner" writes: >> Tom Lane wrote: >>> We'd probably not want to apply this as-is, but should first >>> tighten up what characters URLPath allows, per Kevin's spec >>> research. > >> If we're headed that way, I figured I should double-check. The >> RFC I referenced was later obsoleted by: >> http://www.ietf.org/rfc/rfc3986.txt > > On reflection, since we're changing the behavior anyway, it seems > like the most defensible thing to do is make the TS parser follow > the RFC's allowed character set exactly. The newer RFC doesn't > restrict '#' so that possible corner case is gone. It seems worth mentioning that there is a BSD licensed URI parser on sourceforge: http://uriparser.sourceforge.net/ I'm not advocating for using it, I just ran across it and it seemed of possible interest. -Kevin -- 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 with Tsearch and tsvector
Tom Lane wrote:
> We'd probably not want to apply this as-is, but should first
> tighten up what characters URLPath allows, per Kevin's spec
> research.
If we're headed that way, I figured I should double-check. The RFC
I referenced was later obsoleted by:
http://www.ietf.org/rfc/rfc3986.txt
I haven't been able to find anything more recent. This newer RFC
doesn't seem to list characters which are *not* part of a URI, so
here are the characters which *are* allowed:
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
I'll read this RFC closely and follow up later today.
-Kevin
--
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 with Tsearch and tsvector
Tom Lane wrote: > there's a potential compatibility issue here, so my thought is to > apply this only in HEAD. Agreed. -Kevin -- 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 with Tsearch and tsvector
Tom Lane wrote:
> Hmm, thanks for the reference, but I'm not sure this is specifying
> quite what we want to get at. In particular I note that it
> excludes '%' on the grounds that that ought to be escaped, so I
> guess this is specifying the characters allowed in an underlying
> URI, *not* the textual representation of a URI.
I'm not sure I follow you here -- % is disallowed "raw" because it
is itself the escape character to allow hexadecimal specification of
any disallowed character. So, being the escape character itself, we
would need to allow it.
Section 2.4, taken as a whole, makes sense to me, and argues that we
should always treat any text representation of a URI (including a
URL) as being in escaped form. If it weren't for backward
compatibility, I would feel strongly that we should take any of the
excluded characters as the end of a URI.
| A URI is always in an "escaped" form, since escaping or unescaping
| a completed URI might change its semantics. Normally, the only
| time escape encodings can safely be made is when the URI is being
| created from its component parts; each component may have its own
| set of characters that are reserved, so only the mechanism
| responsible for generating or interpreting that component can
| determine whether or not escaping a character will change its
| semantics. Likewise, a URI must be separated into its components
| before the escaped characters within those components can be
| safely decoded.
> Still, it seems like this is a sufficient defense against any
> complaints we might get for not treating "<" or ">" as part of a
> URL.
I would think so.
> I wonder whether we ought to reject any of the other characters
> listed here too. Right now, the InURLPath state seems to eat
> everything until a space, quote, or double quote mark. We could
> easily make it stop at "<" or ">" too, but what else?
>From the RFC:
| control =
| space =
| delims = "<" | ">" | "#" | "%" | <">
| unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
Except, of course, that since % is the escape character, it is OK.
Hmm. Having typed that, I'm staring at the # character, which is
used to mark off an anchor within an HTML page identified by the
URL. Should we consider the # and anchor part of a URL? Any other
questionable characters?
-Kevin
--
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 with Tsearch and tsvector
Tom Lane wrote: > ie the critical point seems to be that url_path is willing to soak > up a string containing "<" and ">", so the span tags don't get > recognized as separate lexemes. While that's "obviously" the > wrong thing in this particular example, I'm not sure if it's the > wrong thing in general. Can anyone comment on the frequency of > usage of those two symbols in URLs? http://www.ietf.org/rfc/rfc2396.txt section 2.4.3 "delims" expressly forbids their use in URIs. > In any case it's weird that the URL lexeme doesn't span the same > text as the url_path one, but I'm not sure which one we should > consider wrong. In spite of the above prohibition, I notice that firefox and wget both seem to *try* to use such characters if they're included. -Kevin -- 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 #5438: Bug/quirk in ascii() function
Christoph Zwerschke wrote:
> Am 26.04.2010 12:11, schrieb Takahiro Itagaki:
>> Do you know how the SQL standard mention the behavior? IMHO,
>> postgres' behavior is more reasonable because
>> length(' '::char(1)) is 0.
>
> Just found http://troels.arvin.dk/db/rdbms/ which claims that this
> is against the standard:
>
>"PostgreSQL: Stores CHARs in space padded form, but violates
> the standard by (conceptually) truncating trailing white-space
> before performing most functions, operators, and comparisons
> (like the CHARACTER_LENGTH-function and the concatenation(||)
> operator)."
>
> Not sure if this is correct and how well-defined the SQL standard
> actually is in this regard. It seems Oracle does not remove
> trailing spaces when converting from char to varchar.
That is consistent with how I remember the standard (although I
don't have time right now to fight my way through it to confirm).
My recollection is that char(n) should be treated exactly like a
varchar padded with spaces to n characters *except* for character
string comparisons, where trailing spaces are supposed to be
ignored.
-Kevin
--
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 #5439: Table crash after CLUSTER command
"Stefan Kirchev" wrote: > PostgreSQL version: 8.3.3 > Description:Table crash after CLUSTER command > I order to keep good performance on tables CLUSTER is done > regularly on each table every Sunday. Almost every time we loose a > table which must be recreated afterward. The error yield is: > pnp=# select * from alcatel_bss_kpi_tmp.cs_hourly_kpi limit 1; > ERROR: could not open relation 1663/16404/2426042: No such file > or directory My first recommendation would be to apply the fixes for the bugs found during the last two years by upgrading your executable to 8.3.10. This does not require a dump and load, but if you have any GiST indexes, or if you have hash indexes on intervals, you will need to rebuild those indexes. To get more details, see: http://www.postgresql.org/docs/8.3/static/release FWIW, we CLUSTER a few very small, very frequently updated tables daily in about 100 databases to ensure that we recover from bloat from the occasional long-running transaction, and we've *never* seen this. If you actually need to cluster *every* table *every* week, you should review your vacuum policy. -Kevin -- 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 #5437: Production db down
"shanmugavel" wrote: > Description:Production db down > now i face the problem > > how can i resolve that the problem > [cut and paste from an archive post from three years ago > about a non-production version under development] You've actually given no information about what problem you have or what version of PostgreSQL you're running. Please review this page: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems Also, you'll get best results posting to a list which fits the topic. http://www.postgresql.org/community/lists/ Unless you have some reason to believe there's a PostgreSQL bug involved, it would be better to start a discussion of a production problem on the pgsql-admin or pgsql-general list. -Kevin -- 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] query related to pgsql
Abhishek Maurya wrote: > while connecting php with database created in postgres,we r facing > one error ..errror is that its demanding a password of > postgres..but while installing or using postgres we hadnt gave any > password.. so hw cn we solve this problem.. You haven't really given enough information to allow me to advise you with much confidence. In general, you might want to check the documentation of the pg_hba.conf file. If this doesn't do it for you, please read the "Guide to reporting problems" page: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems If you repost, you should choose a more appropriate list, like pgsql-admin or pgsql-general. Oh, and messages are easier to read and understand if some attempt is made at conventional spelling, capitalization, and punctuation. I understand that many posters don't speak English as their first language, but please do what you can. -Kevin -- 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 #5431: CREATE USER is not case sensitive, but psql command line arguments are
Alvaro Herrera wrote: > you'd be required to type something like > psql \"nEWuSer\" Although we do that with some command-line arguments, like the pg_dump -t switch. Not arguing for any particular course here, just noting the inconsistency. -Kevin -- 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] bugs that have not been replied-to on list
Tom Lane wrote: > IME many of the bugs that go unanswered are non-bugs (eg #5316) > or inadequately described (eg #5429) Agreed. > If the goal is "make sure nothing important slips through the > cracks", a tracker could help. If the goal is "100% response rate > to pgsql-bugs submissions", the only thing that will actually help > is a lot more people willing to do marginally-useful dogwork. Actually, if we had has something I could review to easily spot them as unanswered, I probably would have responded to #5316 long ago. (I'm not sure whether it makes sense to respond after two and a half months.) I don't know whether the message fell victim to our (rather aggressive) spam filters or I initially blew past it for some reason, but had I been able to review a list of pending issues, I'm sure I'd have picked it up. I intentionally skipped #5429 because I thought the description in the post might mean something to someone familiar with ODBC access to PostgreSQL. If we had a tracking system, I'd have probably responded if nobody else did after two or three days, to suggest another list or request more detail. I will often hang on to emails to which I don't initially reply, to remind me to follow up, but I find that clumsy and error-prone, and I have the disheartening feeling that there are other people doing exactly the same thing, leading to duplicated (wasted) effort. I don't think it has to be fancy, but setting up something to track open issues (linking to the related list archive pages) seems like a good idea to me. -Kevin -- 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 #5421: pg_attribute broken
"cool shower" wrote: > PostgreSQL version: 8.1.8 > Q2:Does anything have repair patches ? You may want to review the fixes between 8.1.8 and the latest 8.1 bug fix release, which is 8.1.20: http://www.postgresql.org/docs/8.1/static/release.html Perhaps one of these fixes would help. I'd certainly recommend applying the bug-fix update and seeing if the problem is still there. -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Can you please let me know?
Gaurav K Srivastav wrote: > Suppose I created a function getage(id character varying). > Now Is there any query in postgreSQL that I can retreive the name > of all user difned/system function in the database schema. > like "select VIEW_TYPE_OWNER, VIEW_TYPE, OID_TEXT from user_views" > will list all views in oracle. If you are using psql: \df To see detail: \df+ Use \? to get more detail. -Kevin -- 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] pgadmin supports on SLES10.3
Please keep the list copied, so others can contribute, know the status, and future users with problems can find the resolution of the issue. manohar cr wrote: > i have SuSe Linux Enterprise Server(SLES) 10 SP 3 > > my question is.. does pgadmin works on this version??. I was going to try it out to see, but there's no package for it showing in YAST, and I don't really know how you're attempting to install or what version. I would expect it to work, though. > if yess.. i will try to fix the error which is showing.. Sure, go for it. If it still doesn't work, please re-post with the details of where you got the software, what version it is, exactly how you're trying to apply it, and what the error message is. (Without any of that, it's hard to know what to suggest.) -Kevin -- 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] bugs that have not been replied-to on list
Andy Balholm wrote: > On Apr 9, 2010, at 5:08 AM, Robert Haas wrote: > >> Something is wrong with this mailing list. > > In the week and a half that I've been subscribed to this mailing > list, there have been several times that I received a reply to a > message without receiving the original message. In most cases, I > received the original message a few minutes to a few hours later. I've seen that sometimes, too. It's usually preceded by an eerie "calm" without many (or any) messages. I don't know whether the bottleneck is on our end (the emails go through many anti-spam filters before they reach me, and I know they sometimes fall behind). The other issue which has caused me to see replies to messages I missed is that some of the posters here are going through SMTP servers on networks segments which have been blacklisted as sources of spam. Since I have things configured to not send me duplicates when the post is to me and a list (or to multiple lists), if a blacklisted user copies me directly I don't get anything. When I identify such a user I let them know and get them whitelisted on my end, but that's hit or miss. -Kevin -- 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] pgadmin supports on SLES10.3
manohar cr wrote: > I am trying to install pgadmin on Suse Linux Enterprise version > 10.3. I've never heard of that. I've heard of openSUSE 10.3 and I've heard of SuSE Linux Enterprise Server (SLES) 10 SP3. They're not at all the same thing. Which do you have? -Kevin -- 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 #5408: Failed to connect to the database
"omar" wrote: > PostgreSQL version: 8.0.0 > Operating system: XP Professional SV2 The earliest version of PostgreSQL supported on Windows is 8.2. You should be running a recent version of any release -- the 8.0 major release is up to a 8.0.24 bug patch release, which fixes many security and data-eating issues. > PostgreSQL 8.0.0 is one of the applications included in MoteWorks > platform (from Crossbow Technology Inc,) Why would that do that, instead of a supported version? I would suggest contacting them to see whether their software works with something supported and patched to a recent revision. See: http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy and: http://www.postgresql.org/support/versioning -Kevin -- 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] dividing money by money
John R Pierce wrote: > Chris Travers wrote: >> Hmm... Back to the drawing board on that helper module :-). > > like I said, its a big tarpit. If you start up on this again, you might want to start a new thread with a more descriptive subject. Those who weren't interested in Andy's issue might not be following your discussion. The proposed new types and conversion capabilities really have nothing to do with the original topic, which makes it kinda confusing. -Kevin -- 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] dividing money by money
Andy Balholm wrote: > OK. Here is the whole thing in C Cool! I'll take it for a spin when I get a little time. I guess there's not much point adding that TODO item now. ;-) -Kevin -- 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] dividing money by money
Andy Balholm wrote: >> That's hardly an improvement if you're concerned about lack of >> exactness. > > I know; I lose a couple of digits by using float8 instead of > numeric, but it's much simpler and faster It also has the advantage of being symmetrical with the other operators. > and if it returned numeric people would _think_ it was exact. Well, I don't know how many people would expect an *exact* decimal representation of dividing a number by three. The case which had me concerned was specifically division by one as a "back door" cast. With numeric we could guarantee *that* was exact. > And if we have a cast to numeric, people who want those extra > digits can cast to numeric before dividing. And nobody has much reason to do the divide-by-one trick. > But I do still have the numeric code that I tried, so if that's > how people want to do it, I can provide it. I'm inclined to think it's better to have an explicit cast from money to numeric, as long as it is exact, and leave the division of money by money as float8. It does sort of beg the question of whether we should support a cast back in the other direction, though. I think that would wrap this all up in a tidy package. -Kevin -- 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] dividing money by money
Andy Balholm wrote: > quotient = (float8)dividend / (float8)divisor; > PG_RETURN_FLOAT8(quotient); That was my first inclination, but the fact that two different people talked about using division by '1'::money as a way to convert money to another type has me nervous about using an approximate type. Any chance you could rework it using numeric? I know it's less trivial that way, but unless we provide a cast to numeric, I'm afraid people will use the above trick, assign it to a numeric variable or column, and then wonder why they've lost precision. Or I guess we could leave this as you've written it and add support for a cast from money to numeric. -Kevin -- 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] dividing money by money
Chris Travers wrote: > Just thinking about the more general problem and how things could > be handled more gracefully... Sure, but in the meantime, consider: test=# select '12'::money * '2'::numeric; ?column? -- $24.00 (1 row) test=# select '24'::money / '2'::numeric; ?column? -- $12.00 (1 row) test=# select '24'::money / '12'::money; ERROR: operator does not exist: money / money LINE 1: select '24'::money / '12'::money; ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. So we support: a * b = c c / b = a but don't even *think* about c / a = b ??? The OP just wanted to add some symmetry to this, so that the existing class could handle a not-uncommon use case more easily. As far as I can see, the implementation of this operator could convert two int64 values to numeric values and perform numeric division to get the result. (I was going to mark the TODO as an easy one.) I don't see how this change would affect what you want to do, one way or the other. -Kevin -- 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] dividing money by money
I wrote: > yielding some non-money numeric type (like perhaps float8). Hmmm... Given that we've already had a couple posts on the idea that dividing by '1'::money could convert money to something more general, I guess it would be safer to stick to numeric. -Kevin -- 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] dividing money by money
Chris Travers wrote: > With due respect, this sort of thing is rather difficult to get > right all at once. The existing type is fixed point and we know how to add and subtract two of them. I don't think it's all that difficult to add division, yielding some non-money numeric type (like perhaps float8). Neither do I see it as a particularly slippery slope. If someone has a list of other things they want to do for monetary types -- I don't see that it has anything to do with this particular request, unless some convincing argument can be made that adding this would make the other features harder to implement. Do we have to take a simple request for something useful and blow it up into something grand and complicated? Well, I mean, *every* time? ;-) The grander aspects of this thread would make more sense as a separate thread for a longer-term effort, probably for a new type (or set of types). -Kevin -- 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] dividing money by money
John R Pierce wrote: > Boszormenyi Zoltan wrote: >> But then any operator between two money values would >> only work if both values have the same currency. That sounds like a sane limitation. > and, are there still any currenccies like old style UK where > the subunits aren't 100ths? schillings or whatever I'm not sure if you're arguing for or against the database type knowing how to divide those to get a percentage, versus putting the onus on the application programmer. Where does it make the most sense to you to put such logic? -Kevin -- 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] dividing money by money
Andy Balholm wrote: > The ability to divide money by money would be useful for finding > what percent one money value is of another. That certainly sounds useful and natural to me. I don't think it rises to the level of a *bug*, but it's a reasonable request for enhancement. If there are no objections I'll add it to the TODO list. -Kevin -- 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 #5377: group by problem
"michel rosa" wrote: > I get extras rows for 2010-03-02 I'm not sure I understand your concern. Is it that the result set includes these rows?: > to_char | cost | count > +--+--- > 2010-03-02 | 2.0 | 7 > 2010-03-02 | 3.0 | 3 What do you get from?: select * from evadeo.tileshop where status=2 and source=3 and upload_date = '2010-03-02' and cost > 1.5; -Kevin -- 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] what can i do
vladislav DONCHEV wrote: > Hello guys , i have a problem :( I had a postgreSQL before some > days but i delete it , and now i cant install it , cause there are > 2 message at the end of install when it making account or > something like that You haven't told us what operating system you're using, what version of PostgreSQL, how you're trying to install it, or what the messages are. Please read this: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems Then repost, with more information, to the general or novice list. This doesn't sound like a bug. -Kevin -- 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] update the same tuple in one command twice
"terry" <94487...@qq.com> wrote: > In one command, why can we update the same tuple for twice? > TEST=# update t1 set a = t2.d from t2 where a=t2.c; > UPDATE 1 It says it updated it once. Why do you think otherwise? > And the result is not predicated!! When you select multiple rows without specifying an order, the order cannot be reliably predicted. If you want the update to pick a particular row as the source for the update, tell it which one. Something like: update t1 set a = t2.d from t2 where a=t2.c and not exists ( select * from t2 x where x.c = a and x.d > t2.d -- or whatever logic you want here ) ; -Kevin -- 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 #5373: Crash at the first time system bootup
"Bhavin" wrote: > PostgreSQL version: postgresSQL 8.4 > Operating system: windows xp > Description:Crash at the first time system bootup > My postgreSQL 8.4 crashes everytime at the first bootup of my > system. It works fine after first system bootup. > > What could be the possible reason? What messages are logged? As a guess, in the absence of any detail to suggest otherwise, is that the service isn't defined with a needed dependency. -Kevin -- 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 #5369: can't install it
"Bassem Fennani" wrote: > Description:can't install it > I could not install postgresql on the desktops in the office : IBM > IntelliStation Z Pro with Xeon processors. That's not enough information for us to have much chance of guessing your problem. Please read this page: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems When you post with the additional information, you should really go to another list, like general or novice. This is almost certainly not a bug. -Kevin -- 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 #5354: Type timestamptz doesn't allow to store time zone
Robert Haas wrote: > Vitali wrote: >> When I select from the table, the timetz has the correct time >> zone, the timestamptz has -6 as a time zone, which is my server >> default. > > I'm not sure what you think the bug is, but timestamptz definitely > doesn't store the time zone in which the value is input. What it > does is makes input and output relative to the then-current time > zones rather than fixed wall-clock times. We should probably add this to the FAQ -- the OP was expecting the behavior specified by the standard, in which TIMESTAMP WITH TIME ZONE includes a time zone. -Kevin -- 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
Bruce Momjian wrote: > I think you should just edit the TODO wiki and list all the things > we agree need fixing: Done, although with the wealth of opinions and dearth of agreement I referenced much material and said that more discussion was needed before starting development. If anyone figures I missed anything or got overly expansive, have it it. ;-) -Kevin -- 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 #5342: Error
"Shilpa.R" wrote: > PostgreSQL version: PostgreSQL Data That's not very informative; what do you get from running?: select version(); > I found an error stating syntax error near or at sets in the > following query > select agegrp, cartype, risk, count(*) as count > from trset > group by risk, grouping sets ((agegrp,cartype)) I'm not familiar with "grouping sets" -- where in the PostgreSQL documentation do you find those defined? -Kevin -- 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
Bruce Momjian wrote: > I think you should just edit the TODO wiki and list all the things > we agree need fixing Will do. It may take me a while to chase down all the issues from the LSB script work. If I recall correctly, some of what I was looking at seems necessary for a well-behaved LSB conforming script, and there was support for the ideas from some quarters, but it fell short of what I'd consider a consensus (for example, escalating the stop request level over time). Do we want to get into a discussion of such issues at this point, add them to the list with a note that discussion is needed before undertaking them, or should I keep them just in my own list? A couple comments which I think were the last on the escalation of stop mode: http://archives.postgresql.org/pgsql-hackers/2009-09/msg01145.php http://archives.postgresql.org/pgsql-hackers/2009-09/msg01158.php Before continuing that discussion, I think we need to decide if *now is the time* to continue that discussion (and other related ones); and I would argue such discussion should wait. These links are just provided to help answer the question of what I should do with such disputed issues when I update the TODO list. I don't want to slip something in without consensus, but I don't want the issue to be lost, or missed by anyone who takes on pg_ctl work. -Kevin -- 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
Bruce Momjian wrote: > Was this ever addressed? It should probably be on the TODO list. I was going to try to do this along with other items which came out of generating an LSB conforming init script, but have been pulled in different directions for now. When I get the time I've been intending to get back to this, if nobody beats me to it. Do we want one entry with all the miscellaneous pg_ctl issues I've got, or would it be better to keep the separate? -Kevin -- 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] helo
Kris Jurka wrote: > You need to pass an instance of java.sql.Array, not a Collection > or something else that is array like. Ah, right. After extracting an array from the java.util.ArrayList, it needs to be turned into a java.sql.Array using the Connection.createArrayOf method. Most definitely not a PostgreSQL bug. -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: Fwd: [BUGS] exception in plsql
Ravi wrote: > when I tried to use the toArray method to extract exception raised > saying > > org.postgresql.util.PSQLException: Cannot cast an instance of > [Ljava.lang.Object; to type Types.ARRAY OK, that looks like an array, so I'm now a bit lost. Could you put together a self-contained example of how to create the problem? (Self-contained meaning that I can take what you provide and run it, without writing any Java or plpgsql code or inventing table or type definitions -- which might or might not match what you did well enough to show the problem.) It's most helpful if you keep removing things until you have the *smallest* example which still shows the problem. -Kevin -- 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] exception in plsql
beulah prasanthi wrote: > org.postgresql.util.PSQLException: Cannot cast an instance of > java.util.ArrayList to type Types.ARRAY* An ArrayList is not an array -- it is a List implementation which uses an array, internally. What happens if you use the toArray method to extract an array from the List and pass that in? -Kevin -- 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 #5308: How to disable Case sensitivity on naming identifiers
Tom Lane wrote: > "Key words and unquoted identifiers are case insensitive..." FWIW, that is the *exact* rewording that came to mind for me as a possible solution. -Kevin -- 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 #5308: How to disable Case sensitivity on naming identifiers
Chris Travers wrote: > It is probably understandable that some people > would miss it (I did, a moment ago, until you mentioned it). That seems like pretty good evidence that a footnote or qualification of the initial statement would occasionally save some confusion. -Kevin -- 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 #5301: difference of behaviour between 8.3 and 8.4 on IS NULL with sub rows of nulls
"Jehan-Guillaume (ioguix) de Rorthais" wrote: > and here is another test case where 8.3 is inconsistent with > *himself* this time: Sounds like an argument that the behavior *should* have changed in 8.4. We don't like to introduce behavioral changes which might break something in a minor release, so I doubt we'd change that in 8.3; but on a major release like 8.4, this sort of fix is fair game. So you found broken behavior in 8.3 which we can't fix without risking breaking users' applications, and a fix implemented in 8.4 when such risk is acceptable? Is there something else? -Kevin -- 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 #5299: unable to start postgres service
"Savita" wrote: > I have installed postgres. When I check the status of postgres > service I get it is not running. But when I start pg_ctl start it > says server starting. But server is actually not started. How do > we get debug information for pg_ctl start? This doesn't sound like a bug; it's probably an installation or configuration problem. Another list, like admin, general, or novice would be more appropriate. When it says it is starting, that means it is attempting to start. Apparently it is not succeeding. There should be some sort of log entries, either to the console or to a file, if you specified the -l switch to pg_ctl. Assuming you have permission to write to the directory specified by -l and you haven't redirected the log to /dev/null or some such, you should find something there which will probably be useful. -Kevin -- 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 #5284: Postgres CPU 100% and worker took too long to start; cancelled... Systemdown
yua ** wrote: > PostgreSQL 8.3.3 on i386-portbld-freebsd7.0, compiled by GCC cc (GCC) > 4.2.1 20070719 [FreeBSD] >postgres[681]: [506-1] WARNING: worker took too long to start; cancelled > Nov 12 11:15:12 kddi-nwmgr01 postgres[681]: > [507-1] WARNING: worker took too long to start; cancelled > ps -auxeww > -+-+-+-+-+-+ > USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > pgsql 682 99.0 0.1 9336 2740 ?? Rs 27Nov08 343573:19.27 USER=pgsql > Q6 PostgreSQL Programs > A6 php5-pdo_pgsql-5.2.12 > p5-DBD-Pg-2.16.0 > Q8 OS Version > A8 FreeBSD 7.0-RELEASE-p2 > CPU : Intel, Xeon2.4 > RAM : 2GB > Storage > RAID Card : LSI MegaRAID > Battery Cache : YES > write-back Cache : NO > Software RAID : NO ( Hardware RAID) > SAN : NO > Disk : 7,200rpm SATA 3lot > Disk : RAID5 3slot This is starting to sound like some other reports from FreeBSD. http://archives.postgresql.org/pgsql-general/2008-06/msg00934.php http://archives.postgresql.org/pgsql-general/2010-01/msg01076.php Unfortunately, the other posters didn't post back with information on resolution of the issue. Could you read Tom's advice and report back?: http://archives.postgresql.org/pgsql-general/2010-01/msg01079.php -Kevin -- 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 #5292: Corrupted installer
Adam, please keep the discussion on-list. For one thing, I don't have any Windows machines to test this on; I was just trying to elicit enough information that when someone who did looked at the thread, they'd have enough information to try to replicate it. Adam 'foo-script' Rakowski wrote: > MD5 of "One click installer" from > http://www.enterprisedb.com/products/pgdownload.do , file > "postgresql-8.4.2-1-windows.exe" is > F59C645AC9CBFC5BBF1A52F734EAA550 MD5 of > "postgresql-8.4.2-1-windows-binaries.zip" is > EDC5737933DB459FCBFCCDFBE2D61240 (same source). > > See the attachment. "Uszkodzony" means "corrupted". > > > Dnia 20 stycznia 2010 16:21 "Kevin Grittner" > > napisa*(a): > >> "Adam Rakowski" wrote: >> >> > Both one-click installer and zip archive from postgresql.org >> > are corrupted. >> >> Where did you get them (e.g., a URL)? >> >> Any chance of download problems? >> >> -Kevin -- 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 #5293: constant function (date_trunc) is repeatedly evaluated inside loop
Richard Neill wrote:
> #fast
> WHERE column < '2010-010-20 00:00:00'
>
> #fast
> WHERE column < date_trunc('day', timestamp with time zone
> '2010-01-20 10:16:55')
>
> #slow
> WHERE column < date_trunc('day', timestamp
> '2010-01-20 10:16:55')
>
>
> Why is that, I wonder?
The column is timestamp with time zone, and the fast options
generate a value of the same type (the first because the literal is
treated as UNKNOWN type until the comparison). It's generally a
good idea to use literals which match the type of the column. How
much work it would be to optimize the slow case to insert a cast of
the date_trunc function return value to a different type before
entering the loop where the value is tested, I don't know offhand.
-Kevin
--
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 #5292: Corrupted installer
"Adam Rakowski" wrote: > Both one-click installer and zip archive from postgresql.org are > corrupted. Where did you get them (e.g., a URL)? Any chance of download problems? -Kevin -- 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 #5293: constant function (date_trunc) is repeatedly evaluated inside loop
"Richard Neill" wrote:
> date_trunc('day', timestamp '2010-01-20 10:16:55')
What happens with a "timestamp with time zone" literal?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
