Re: [BUGS] BUG #6510: A simple prompt is displayed using wrong charset
I see two ways to resolve the issue.
First is to use CharToOemBuff when writing a string to the "con" and
OemToCharBuff when reading an input from it.
The other is to always use stderr/stdin for Win32 as it was done for
msys before. I think it's more straightforward.
I tested the attached patch (build the source with msvc) and it fixes
the issue. If it looks acceptible, then probably DEVTTY should not be
used on Windows at all.
I found two other references of DEVTTY at
psql/command.c
success = saveHistory(fname ? fname : DEVTTY, -1, false, false);
and
contrib/pg_upgrade/option.c
log_opts.debug_fd = fopen(DEVTTY, "w");
By the way, is there any reason to use stderr for the prompt output, not
stdout?
Regards,
Alexander
16.03.2012 23:13, Alvaro Herrera пишет:
Excerpts from exclusion's message of sáb mar 03 15:44:37 -0300 2012:
I'm using postgresSQL in Windows with Russian locale and get unreadable
messages when the postgres utilities prompting me for input.
Please look at the screenshot:
http://oi44.tinypic.com/aotje8.jpg
(The psql writes the unreadable message prompting for the password.)
But at the same time the following message (WARINING) displayed right.
I believe it's related to setlocale and the difference between OEM and ANSI
encoding, which we had in Windows with the Russian locale.
The startup code of psql sets locale with the call setlocale(LC_ALL, "") and
MSDN documentation says that the call:
Sets the locale to the default, which is the user-default ANSI code page
obtained from the operating system.
After the call all the strings printed with the printf(stdout) will go
through the ANSI->OEM conversion.
But in the simple_prompt function strings written to con, and such writes go
without conversion.
Were you able to come up with some way to make this work?
--- original/src/port/sprompt.c 2012-02-24 02:53:36.0 +0400
+++ fix/src/port/sprompt.c 2012-03-17 18:52:15.010559900 +0400
@@ -60,14 +60,13 @@
* Do not try to collapse these into one "w+" mode file. Doesn't work on
* some platforms (eg, HPUX 10.20).
*/
+#ifdef WIN32
+ termin = stdin;
+ termout = stderr;
+#else
termin = fopen(DEVTTY, "r");
termout = fopen(DEVTTY, "w");
- if (!termin || !termout
-#ifdef WIN32
- /* See DEVTTY comment for msys */
- || (getenv("OSTYPE") && strcmp(getenv("OSTYPE"), "msys") == 0)
-#endif
- )
+ if (!termin || !termout)
{
if (termin)
fclose(termin);
@@ -76,6 +75,7 @@
termin = stdin;
termout = stderr;
}
+#endif
#ifdef HAVE_TERMIOS_H
if (!echo)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Fw: Bug in postgresql 8.1
Below error occurs only when i restart postgre 8.1 service when applicaion is running. Otherwise it works fine, but while application is running and i restart postgre 8.1 service. Application crashes. Please refer to below email. Regards, Prem --- On Sun, 18/3/12, prem tolani wrote: > From: prem tolani > Subject: Bug in postgresql 8.1 > To: pgsql-bugs@postgresql.org > Date: Sunday, 18 March, 2012, 10:41 AM > Please refer to below mail and help, > i need urgent help. > > Thanks in advance. > > Regards, > Prem > > > > > I get below error message> > > > > > PG "FATAL:� could not reattach to shared memory > > > (key=5432001, addr=0210): Invalid > > > > argument. > > > > > > > This messages occurs in windows 7 eventviewer log. > > Application log / postgresql log do not show anything. > It is > > custom application made in java. When application is > running and i restart postgresql service, the application > crashes. What could be probable reason and solution to this > ? > > > > If you need more info do let me know. > > > > Regards, > > Prem > > > > > > > > --- On Sun, 18/3/12, Adrian Klaver > > wrote: > > > > > From: Adrian Klaver > > > Subject: Re: [GENERAL] One more query > > > To: "prem tolani" > > > Cc: pgsql-gene...@postgresql.org > > > Date: Sunday, 18 March, 2012, 2:09 AM > > > On 03/17/2012 12:04 AM, prem tolani > > > wrote: > > > > Hi Tom, > > > > > > > > I am using one postgresql 8.1, when my > application > > in > > > java is running and i restart the postgresql 8.1 > > service, my > > > application crashes. Can you please tell me what > could > > the > > > probable fix for this ? I am using windows 7(32 > bit). > > This > > > does not happen on windows xp. can u please tell > me > > what > > > could be the probable reason for that ? > > > > > > This is going to need a lot more information to > get an > > > answer:) > > > > > > Are any error messages shown? > > > > > > What is the application ? > > > Is it custom or a known application? > > > > > > What do the logs say? > > > Postgres > > > Application > > > Windows > > > > > > > > > > > regards, > > > > Prem > > > > > > > > > > > > > -- Adrian Klaver > > > adrian.kla...@gmail.com > > > > > > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Bug in postgresql 8.1
Please refer to below mail and help, i need urgent help. Thanks in advance. Regards, Prem > I get below error message> > > > PG "FATAL:� could not reattach to shared memory > > (key=5432001, addr=0210): Invalid > > > argument. > > > > This messages occurs in windows 7 eventviewer log. > Application log / postgresql log do not show anything. It is > custom application made in java. When application is running and i restart > postgresql service, the application crashes. What could be probable reason > and solution to this ? > > If you need more info do let me know. > > Regards, > Prem > > > > --- On Sun, 18/3/12, Adrian Klaver > wrote: > > > From: Adrian Klaver > > Subject: Re: [GENERAL] One more query > > To: "prem tolani" > > Cc: pgsql-gene...@postgresql.org > > Date: Sunday, 18 March, 2012, 2:09 AM > > On 03/17/2012 12:04 AM, prem tolani > > wrote: > > > Hi Tom, > > > > > > I am using one postgresql 8.1, when my application > in > > java is running and i restart the postgresql 8.1 > service, my > > application crashes. Can you please tell me what could > the > > probable fix for this ? I am using windows 7(32 bit). > This > > does not happen on windows xp. can u please tell me > what > > could be the probable reason for that ? > > > > This is going to need a lot more information to get an > > answer:) > > > > Are any error messages shown? > > > > What is the application ? > > Is it custom or a known application? > > > > What do the logs say? > > Postgres > > Application > > Windows > > > > > > > > regards, > > > Prem > > > > > > > > > -- Adrian Klaver > > adrian.kla...@gmail.com > > > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Fw: Bug in postgresql 8.1
On Sun, Mar 18, 2012 at 12:13 AM, prem tolani wrote: > Below error occurs only when i restart postgre 8.1 service when applicaion is > running. Otherwise it works fine, but while > application is running and i restart postgre 8.1 service. Application > crashes. Please refer to below email. > postgres 8.1 is not currently supported (since November 2010, http://www.postgresql.org/support/versioning), so is likely that if something was done in postgres to support win7 it hasn't reach 8.1 the best "fix" you can get is to migrate to a newer supported version as soon as possible. -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- 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 in postgresql 8.1
On Sunday, March 18, 2012, Jaime Casanova wrote: > On Sun, Mar 18, 2012 at 12:13 AM, prem tolani wrote: >> Below error occurs only when i restart postgre 8.1 service when applicaion is running. Otherwise it works fine, but while >> application is running and i restart postgre 8.1 service. Application crashes. Please refer to below email. >> > > postgres 8.1 is not currently supported (since November 2010, > http://www.postgresql.org/support/versioning), so is likely that if > something was done in postgres to support win7 it hasn't reach 8.1 It hasn't been supported on Windows for *much* longer. > the best "fix" you can get is to migrate to a newer supported version > as soon as possible. +1. Windows 7 will never be a supported platform for 8.1, even if it was still supported in general. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: [BUGS] Bug in postgresql 8.1
On Sun, Mar 18, 2012 at 8:11 AM, Dave Page wrote: > > > On Sunday, March 18, 2012, Jaime Casanova wrote: >> On Sun, Mar 18, 2012 at 12:13 AM, prem tolani >> wrote: >>> Below error occurs only when i restart postgre 8.1 service when >>> applicaion is running. Otherwise it works fine, but while >>> application is running and i restart postgre 8.1 service. Application >>> crashes. Please refer to below email. >>> >> >> postgres 8.1 is not currently supported (since November 2010, >> http://www.postgresql.org/support/versioning), so is likely that if >> something was done in postgres to support win7 it hasn't reach 8.1 > > It hasn't been supported on Windows for *much* longer. > true. i forgot that, support for 8.1 on windows was dropped on 2008 with release of 8.1.11, and it was because of very serious problems. so, not being able to start the database is the less serious of your problems. http://www.postgresql.org/about/news/865 -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- 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 #6535: LEFT JOIN on large table is altering data
Thanks. While creating that very file, I discovered that 1 row had blanks in every field despite a column having a *NOT NULL* constraint and another column being a* *serial. Removing that column appears to fixed the problem. Something about that column made Postgres unhappy, though. If I ran these queries: SELECT COUNT(*) FROM consistent.master WHERE citation_id IS NOT NULL UNION SELECT COUNT(*) FROM consistent.master UNION SELECT COUNT(*) FROM consistent.master WHERE citation_id IS NULL I got this result: 2085344 2085343 0 Not clear how adding a WHERE clause, whose only practical effect is to reduce the number of rows returned, could cause *more* rows to be returned. That seems buggy to me. Aren On Fri, Mar 16, 2012 at 12:56 PM, Tom Lane wrote: > a...@arencambre.com writes: > > (Note that this issue is described fully at > > > http://stackoverflow.com/questions/9713537/postgres-left-join-is-creating-new-data > . > > A few knowledgeable people have weighed in, and there is no solution > > identified.) > > This might be a bug, but you've not provided sufficient information for > someone else to reproduce the problem. What would be good is a SQL > script that reproduces the error from a standing start (empty database). > >regards, tom lane >
Re: [BUGS] BUG #6535: LEFT JOIN on large table is altering data
Aren Cambre wrote: > SELECT COUNT(*) > FROM consistent.master > WHERE citation_id IS NOT NULL > UNION > SELECT COUNT(*) > FROM consistent.master > UNION > SELECT COUNT(*) > FROM consistent.master > WHERE citation_id IS NULL > > I got this result: > > 2085344 > 2085343 > 0 > > Not clear how adding a WHERE clause, whose only practical effect > is to reduce the number of rows returned, could cause *more* rows > to be returned. That seems buggy to me. Never assume that the rows will be returned in any particular order from a query unless you specify ORDER BY. Assuming, as you seem to be doing, that rows from the left side of a UNION will be output before rows from the right side is not safe. You have no way of knowing which row in a result set like that came from which of the UNIONed SELECTs. In this case your assumption is almost certainly wrong. -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 #6535: LEFT JOIN on large table is altering data
Kevin, You're absolutely correct; there's no telling what order the planner will use. I did in fact run the queries separately and got the same result that I intimated in the UNIONed queries. I can no longer reproduce, however, because I have since altered the table. So if there is a bug, I may not be much help in nailing it down. The only thing I can help with is this appears to have happened at row # 583847 of just over 2 million rows, per a straight CSV dump of the table. Aren On Sun, Mar 18, 2012 at 3:22 PM, Kevin Grittner wrote: > Aren Cambre wrote: > > > SELECT COUNT(*) > > FROM consistent.master > > WHERE citation_id IS NOT NULL > > UNION > > SELECT COUNT(*) > > FROM consistent.master > > UNION > > SELECT COUNT(*) > > FROM consistent.master > > WHERE citation_id IS NULL > > > > I got this result: > > > > 2085344 > > 2085343 > > 0 > > > > Not clear how adding a WHERE clause, whose only practical effect > > is to reduce the number of rows returned, could cause *more* rows > > to be returned. That seems buggy to me. > > Never assume that the rows will be returned in any particular order > from a query unless you specify ORDER BY. Assuming, as you seem to > be doing, that rows from the left side of a UNION will be output > before rows from the right side is not safe. You have no way of > knowing which row in a result set like that came from which of the > UNIONed SELECTs. In this case your assumption is almost certainly > wrong. > > -Kevin >
Re: [BUGS] BUG #6535: LEFT JOIN on large table is altering data
"Kevin Grittner" wrote: > Aren Cambre wrote: > >> SELECT COUNT(*) >> FROM consistent.master >> WHERE citation_id IS NOT NULL >> UNION >> SELECT COUNT(*) >> FROM consistent.master >> UNION >> SELECT COUNT(*) >> FROM consistent.master >> WHERE citation_id IS NULL >> >> I got this result: >> >> 2085344 >> 2085343 >> 0 >> >> Not clear how adding a WHERE clause, whose only practical effect >> is to reduce the number of rows returned, could cause *more* rows >> to be returned. > Never assume that the rows will be returned in any particular > order from a query unless you specify ORDER BY. Hmm. That doesn't explain why the numbers don't add up, though. Is that a copy/paste from an actual query run, or was there some hand-editing there? In particular, you might easily get that result if that last line was really: WHERE citation_id = '' instead of the IS NULL test. In the ANSI standard and in PostgreSQL there is a big difference between an empty string and NULL, although there is at least one product I know of which breaks from standard compliance by treating them as equivalent. -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] Applicatin crashing with on postgresql 8.1 service restart
I running an applicatio in java with postgresql 8.1. When I restart the postgre service the application crashes while it it running. I get this error in windows evenviewer. I am using windows 7. PG "FATAL: could not reattach to shared memory (key=5432001, addr=0210): Invalid argument. Please help. Regards -- View this message in context: http://postgresql.1045698.n5.nabble.com/Applicatin-crashing-with-on-postgresql-8-1-service-restart-tp5574959p5574959.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6535: LEFT JOIN on large table is altering data
Kevin, Thanks. That was a direct copy/paste. It happened that the *UNION*ed queries spat out those results in the same order that the queries appeared. Just want to again emphasize that my database state has changed, so I am not sure this is remains a good case for finding a bug. Aren On Sun, Mar 18, 2012 at 3:33 PM, Kevin Grittner wrote: > "Kevin Grittner" wrote: > > Aren Cambre wrote: > > > >> SELECT COUNT(*) > >> FROM consistent.master > >> WHERE citation_id IS NOT NULL > >> UNION > >> SELECT COUNT(*) > >> FROM consistent.master > >> UNION > >> SELECT COUNT(*) > >> FROM consistent.master > >> WHERE citation_id IS NULL > >> > >> I got this result: > >> > >> 2085344 > >> 2085343 > >> 0 > >> > >> Not clear how adding a WHERE clause, whose only practical effect > >> is to reduce the number of rows returned, could cause *more* rows > >> to be returned. > > > Never assume that the rows will be returned in any particular > > order from a query unless you specify ORDER BY. > > Hmm. That doesn't explain why the numbers don't add up, though. Is > that a copy/paste from an actual query run, or was there some > hand-editing there? In particular, you might easily get that result > if that last line was really: > > WHERE citation_id = '' > > instead of the IS NULL test. In the ANSI standard and in PostgreSQL > there is a big difference between an empty string and NULL, although > there is at least one product I know of which breaks from standard > compliance by treating them as equivalent. > > -Kevin >
Re: [BUGS] BUG #6535: LEFT JOIN on large table is altering data
Aren Cambre writes: > Just want to again emphasize that my database state has changed, so I am > not sure this is remains a good case for finding a bug. Your description of an apparently-all-nulls row sounds a great deal like data corruption. I suspect there may be more wrong than just the one row, and that that's what's leading to the inconsistent results. It'd be worthwhile to run hardware diagnostics (memtest, disk tests), make sure you are on the latest minor release of Postgres, and perhaps do a database dump and reload. (If the latter seems impractical, at least consider reindexing everything.) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6535: LEFT JOIN on large table is altering data
Thanks. I am running this on 1 year old hardware on a wholly-encrypted C drive, encrypted with TrueCrypt. I suspect that I would have been alerted already with that or SMART if I had hardware issues? I am on 9.1.3, although I think the data was inserted back when I was running 9.0.x. I upgraded to 9.1 almost as soon as it came out, doing the requisite dumps and reloads. I have also reindexed a couple of times as diagnostic steps. So far, looks like only that one row has data corruption. Aren On Sun, Mar 18, 2012 at 9:33 PM, Tom Lane wrote: > Aren Cambre writes: > > Just want to again emphasize that my database state has changed, so I am > > not sure this is remains a good case for finding a bug. > > Your description of an apparently-all-nulls row sounds a great deal like > data corruption. I suspect there may be more wrong than just the one > row, and that that's what's leading to the inconsistent results. It'd > be worthwhile to run hardware diagnostics (memtest, disk tests), make > sure you are on the latest minor release of Postgres, and perhaps do a > database dump and reload. (If the latter seems impractical, at least > consider reindexing everything.) > >regards, tom lane >
