[BUGS] BUG #3802: cant install
The following bug has been logged online: Bug reference: 3802 Logged by: Craig Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: windows vista Description:cant install Details: Have tried to install the programme via the executable intilation file has ran installation correctly up untill the point where it reads an error "user "postgres" could not be created: Access denied! Even if the name is changed this error will still come up but with the new name replacing the "postgres" section of the error message. Can you please help me, Regards Craig. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3802: cant install
On Thu, Dec 06, 2007 at 12:21:38PM +, Craig wrote: > > The following bug has been logged online: > > Bug reference: 3802 > Logged by: Craig > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2 > Operating system: windows vista > Description:cant install > Details: > > Have tried to install the programme via the executable intilation file has > ran installation correctly up untill the point where it reads an error "user > "postgres" could not be created: Access denied! > > Even if the name is changed this error will still come up but with the new > name replacing the "postgres" section of the error message. Can you please > help me, Regards Craig. Windows Vista support is available from 8.3 and on. For 8.2, you will have to install without doing initdb, and do that part manually. You can also chcek out EnterpriseDB Postgres (their community distribution, not "advanced server") which has Vista fixes for the installer backported. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #3804: initdb.exe cannot be started
The following bug has been logged online: Bug reference: 3804 Logged by: Juergen Zimmermann Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 beta4 Operating system: Windows XP Prof. SP2 Description:initdb.exe cannot be started Details: I wanted to install PG 8.3beta4 with just the ZIP file, i.e. without the installer. When invoking "initdb -A password -E UTF8 -U postgres -W" as an unpriviledged Windows user I get this German error message: "Das angegebene Programm kann nicht ausgeführt werden." Basically this means: "The specified program cannot be executed". Using 8.3beta2 there was no problem ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #3803: Error while sending request to database
The following bug has been logged online: Bug reference: 3803 Logged by: srinath Email address: [EMAIL PROTECTED] PostgreSQL version: PostgreSQL 8.1 Operating system: Linux Description:Error while sending request to database Details: hi, when i connecting my postgresql which giving org.postgresql.util.PSQLException: ERROR: conversion between UNICODE and MULE_INTERNAL is not supported.please send solution about this problem. Thanks in Advance Srinath ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #3790: pg_restore error canceling statement due touser request
Tom Lane escribió: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > I don't advocate changing that ERROR to anything else. The message > > wording, as Tom says, can easily be changed -- I think this patch should > > be enough. Feel free to propose better wording. > > Minor gripe: all three variants of the message should follow the same > sentence construction. So perhaps "canceling autovacuum task". Ok, committed using that wording and spelling. -- Alvaro Herrera http://www.PlanetPostgreSQL.org/ "Some men are heterosexual, and some are bisexual, and some men don't think about sex at all... they become lawyers" (Woody Allen) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #3790: pg_restore error canceling statement due touser request
On Thu, 2007-12-06 at 11:33 -0300, Alvaro Herrera wrote: > Tom Lane escribió: > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > I don't advocate changing that ERROR to anything else. The message > > > wording, as Tom says, can easily be changed -- I think this patch should > > > be enough. Feel free to propose better wording. > > > > Minor gripe: all three variants of the message should follow the same > > sentence construction. So perhaps "canceling autovacuum task". > > Ok, committed using that wording and spelling. Sorry to come in on late on this: That wording is better, but it still doesn't explain why it has occurred or what the user should do about it. I think we will get other complaints saying "why has my autovacuum been canceled?" and "what should I do about this?". Perhaps it should be "canceling autovacuum task; will reschedule when user tasks complete" or "autovacuum canceled temporarily to allow user task to proceed" or something that explains that what has happened is a good thing and the task that has been canceled will be automatically re-tried. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3790: pg_restore error canceling statement due touser request
Simon Riggs escribió: > Sorry to come in on late on this: That wording is better, but it still > doesn't explain why it has occurred or what the user should do about it. > I think we will get other complaints saying "why has my autovacuum been > canceled?" and "what should I do about this?". > > Perhaps it should be > "canceling autovacuum task; will reschedule when user tasks complete" > or > "autovacuum canceled temporarily to allow user task to proceed" > > or something that explains that what has happened is a good thing and > the task that has been canceled will be automatically re-tried. Perhaps the added phrase could be put in a errdetail() or something like that. The problem is detecting that this is really the case. How would it know that it wasn't user-inflicted? -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ "Las navajas y los monos deben estar siempre distantes" (Germán Poo) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3790: pg_restore error canceling statement due touser request
On Thu, 2007-12-06 at 12:03 -0300, Alvaro Herrera wrote: > Simon Riggs escribió: > > > Sorry to come in on late on this: That wording is better, but it still > > doesn't explain why it has occurred or what the user should do about it. > > I think we will get other complaints saying "why has my autovacuum been > > canceled?" and "what should I do about this?". > > > > Perhaps it should be > > "canceling autovacuum task; will reschedule when user tasks complete" > > or > > "autovacuum canceled temporarily to allow user task to proceed" > > > > or something that explains that what has happened is a good thing and > > the task that has been canceled will be automatically re-tried. > > Perhaps the added phrase could be put in a errdetail() or something like > that. The problem is detecting that this is really the case. How would > it know that it wasn't user-inflicted? True. We can say "task will be automatically re-scheduled", so that people understand the message and don't start asking us. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #3790: pg_restore error canceling statement due touser request
Simon Riggs <[EMAIL PROTECTED]> writes: > True. We can say "task will be automatically re-scheduled", so that > people understand the message and don't start asking us. How about "temporarily canceling autovacuum task"? This is accurate regardless of the origin of the SIGINT. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3790: pg_restore error canceling statement due touser request
Tom Lane escribió: > Simon Riggs <[EMAIL PROTECTED]> writes: > > True. We can say "task will be automatically re-scheduled", so that > > people understand the message and don't start asking us. > > How about "temporarily canceling autovacuum task"? This is accurate > regardless of the origin of the SIGINT. "postponing autovacuum task"? -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC "No es bueno caminar con un hombre muerto" ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3799: csvlog skips some logs
"depesz" <[EMAIL PROTECTED]> writes: > Description:csvlog skips some logs The point here is that CSV-format log output doesn't include the DETAIL, HINT, or context (QUERY/STATEMENT/CONTEXT) lines that you might get with normal output. I suppose this was intentional in order to keep the CSV output format manageable, but I have to wonder whether it's really a good idea. I can see the argument that you probably don't need to log HINTs, but the other stuff might be important. Particularly the STATEMENT. Comments? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #3790: pg_restore error canceling statement due touser request
On Thu, 2007-12-06 at 12:24 -0300, Alvaro Herrera wrote: > Tom Lane escribió: > > Simon Riggs <[EMAIL PROTECTED]> writes: > > > True. We can say "task will be automatically re-scheduled", so that > > > people understand the message and don't start asking us. > > > > How about "temporarily canceling autovacuum task"? This is accurate > > regardless of the origin of the SIGINT. > > "postponing autovacuum task"? I prefer Tom's version. It fits better with the ERROR word in front of this text. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [BUGS] BUG #3799: csvlog skips some logs
Tom Lane wrote: > "depesz" <[EMAIL PROTECTED]> writes: > > Description:csvlog skips some logs > > The point here is that CSV-format log output doesn't include the > DETAIL, HINT, or context (QUERY/STATEMENT/CONTEXT) lines that > you might get with normal output. > > I suppose this was intentional in order to keep the CSV output > format manageable, but I have to wonder whether it's really a > good idea. I can see the argument that you probably don't need > to log HINTs, but the other stuff might be important. Particularly > the STATEMENT. Hmm. I think it could be a problem in cases where an error message with identical wording is disambiguated by context. In my VH opinion we shouldn't be losing log info just because we're using a different format. -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J "Linux transformó mi computadora, de una `máquina para hacer cosas', en un aparato realmente entretenido, sobre el cual cada día aprendo algo nuevo" (Jaime Salinas) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [BUGS] BUG #3799: csvlog skips some logs
Andrew Dunstan <[EMAIL PROTECTED]> writes: > I can't see any very good reason for text logs to have different > content from CSV logs. Well, if we want to cram all that stuff in there, how shall we do it? It seems wrong to put all those lines into one text field, but I'm not sure I want to add six more text fields to the CSV format either. Thoughts? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [BUGS] BUG #3799: csvlog skips some logs
Tom Lane wrote: "depesz" <[EMAIL PROTECTED]> writes: Description:csvlog skips some logs The point here is that CSV-format log output doesn't include the DETAIL, HINT, or context (QUERY/STATEMENT/CONTEXT) lines that you might get with normal output. I suppose this was intentional in order to keep the CSV output format manageable, but I have to wonder whether it's really a good idea. I can see the argument that you probably don't need to log HINTs, but the other stuff might be important. Particularly the STATEMENT. Comments? I don't recall making such a conscious intention - not sure about others whose fingers have been in the pie. More likely it's just oversight. In general, I'd say that the log content should be independent of the format. I can't see any very good reason for text logs to have different content from CSV logs. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [BUGS] BUG #3799: csvlog skips some logs
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: I can't see any very good reason for text logs to have different content from CSV logs. Well, if we want to cram all that stuff in there, how shall we do it? It seems wrong to put all those lines into one text field, but I'm not sure I want to add six more text fields to the CSV format either. Thoughts? Really? Six? In any case, would that be so bad? It would mean six extra commas per line in the log file, and nothing much in the log table unless there were content in those fields. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #3803: Error while sending request to database
On Thu, Dec 06, 2007 at 12:34:55PM +, srinath wrote: > when i connecting my postgresql which giving > org.postgresql.util.PSQLException: ERROR: conversion between UNICODE and > MULE_INTERNAL is not supported.please send solution about this problem. Sounds like you have your application using MULE_INTERNAL encoding. Don't do that. A ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #3806: PreparedStatement.setString(String) throws exception
The following bug has been logged online:
Bug reference: 3806
Logged by: Ted Wen
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3beta3
Operating system: Windows
Description:PreparedStatement.setString(String) throws exception
Details:
Code fragment:
String sql = "create table uuidtab(id uuid not null,num int,primary key
(id))";
Statement stmt = conn.createStatement();
stmt.executeUpdate(sql);
sql = "insert into uuidtab
values('8555b4c4-5b3d-41ab-9f0f-c71120a583b1',10)";
stmt.executeUpdate(sql);
sql = "select * from uuidtab where id=?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1, "8555b4c4-5b3d-41ab-9f0f-c71120a583b1");
ResultSet rs = ps.executeQuery();
if (rs.next()) {
System.out.println(rs.getString(1));
}
The last executeQuery() produces the following error message:
org.postgresql.util.PSQLException: ERROR: operator does not exist: uuid =
character varying
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
[BUGS] BUG #3807: SQL : select like statement
The following bug has been logged online: Bug reference: 3807 Logged by: Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.0 beta4 Operating system: WindowsXP Description:SQL : select like statement Details: Why? specific change? statement: select * from CAL_M1 where tag_idx = 1 and logdate like '2007-12%' ERROR: operator does not exist: timestamp without time zone ~~ unknown at character 56 HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. CREATE TABLE CAL_M1( TAG_IDX DECIMAL(6) NOT NULL, LOGDATE TIMESTAMP NOT NULL, DATADECIMAL(15,3) ); 8.0.*/8.1.*/8.2.* is OK. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3801: max_fsm_pages postgresql.conf default != guc.c default
Kris- Thanks for digging into the code for that. Unfortunately, I'm now more confused. > the actual default at initdb time can be set as high as nbuffers * > 50, > where the max shared_buffers is 4096. So the default max_fsm_pages > for a > beefier machine will be 204800 which is what you will find in > postgresql.conf.sample. The initdb was done on an 8-way Opteron with 32GB of RAM. I would have assumed that this satisfied the definition of a "beefier machine", but I got the measly 2 m_f_p setting (and didn't manually change the shared_buffers setting). Initdb was done with 8.2.3 IIRC. > The fact that you have a commented out value in your postgresql.conf > does > not mean it is the default. Really? Comments in postgresql.conf file sayeth: # The # commented-out settings shown in this file represent the default values. # # Please note that re-commenting a setting is NOT sufficient to revert it # to the default value, unless you restart the server. This seems to directly say that the commented out settings are the default values, and furthermore that one must restart to get the indicated default back. Based on your evidence, it seems that the postgresql.conf comment for max_fsm_pages needs revising to indicate that the m_f_p default is determined at initdb-time. Thank you, Reece -- Reece Hart, http://harts.net/reece/, GPG:0x25EC91A0
Re: [HACKERS] [BUGS] BUG #3799: csvlog skips some logs
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Well, if we want to cram all that stuff in there, how shall we do it? >> It seems wrong to put all those lines into one text field, but I'm >> not sure I want to add six more text fields to the CSV format >> either. Thoughts? > Really? Six? In any case, would that be so bad? It would mean six extra > commas per line in the log file, and nothing much in the log table > unless there were content in those fields. Yeah --- the lines output in the plain-stderr case that are not covered in the other are DETAIL HINT QUERY (this is an internally-generated query that failed) CONTEXT (think "stack trace") LOCATION(reference to code file/line reporting the error) STATEMENT (user query that led to the error) One issue here is that CONTEXT is potentially multiple lines. I'm not sure that there is much we can do about that, especially not at the last minute. If we had some time to rewrite internal APIs it might be fun to think about emitting that as array of text not just text, but I fear it's much too late to consider that now. Another thing that I notice is that the CSV code emulates a couple of not-very-orthogonal behaviors of send_message_to_server_log(): substituting "missing error text" for a NULL error field, and emitting cursor pos as a tack-on to the error text instead of a separate field. I think both of those are less than defensible. So if you're willing to entertain redefining the CSV column set at this late date, I'd propose throwing in a seventh new field too: CURSORPOS. Another thing: for stderr output, we have various log verbosity options that determine whether these additional fields get printed. Should those options also function in the CSV-output case, or are we just going to do our best to exhaust disk space as fast as possible all the time? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #3801: max_fsm_pages postgresql.conf default != guc.c default
On Thu, 6 Dec 2007, Reece Hart wrote: This seems to directly say that the commented out settings are the default values, and furthermore that one must restart to get the indicated default back. Based on your evidence, it seems that the postgresql.conf comment for max_fsm_pages needs revising to indicate that the m_f_p default is determined at initdb-time. Yes, the commented out values are the defaults, but after initdb max_fsm_pages is not commented out, which is why I'm suggesting you or some other admin modified your file. Try this test: $ ./tmp/82/bin/initdb -D fsmtest > fsmlog 2>&1 $ grep max_fsm fsmlog selecting default shared_buffers/max_fsm_pages ... 24MB/153600 $ grep max_fsm_pages fsmtest/postgresql.conf max_fsm_pages = 153600 # min max_fsm_relations*16, 6 bytes each So you can see max_fsm_pages is not commented out, so it is not the true default (2). Kris Jurka ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
