[BUGS] BUG #7605: service restart failed
The following bug has been logged on the website: Bug reference: 7605 Logged by: James Email address: jameshun...@163.com PostgreSQL version: 9.2.1 Operating system: CentOS 6.2 Description: When I modify the "listen_addresse" from 'localhost' to '*', postgresql service restart failed. postgresql.conf like below: # - Connection Settings - listen_addresse='*'# what IP address(es) to listen on; -- 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 #7606: service restart failed
The following bug has been logged on the website: Bug reference: 7606 Logged by: James Email address: jameshun...@163.com PostgreSQL version: 9.2.1 Operating system: CentOS 6.2 Description: When I modify the "listen_addresse" from 'localhost' to '*', postgresql service restart failed. postgresql.conf like below: # - Connection Settings - listen_addresse='*'# what IP address(es) to listen on; -- 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 #7577: JDBC Driver - Compiled with Java 7
On 10/15/2012 11:10 PM, seancompusult wrote: Does anyone have a solution for people like me who must use Java 5? I had no problems building current git head of the JDBC driver with Java SE 5, nor the REL_9_2_STABLE branch. export PATH=$HOME/java/jdk1.5.0_22/bin:$HOME/java/jdk1.5.0_22/jre/bin:$PATH; export JAVA_HOME=$HOME/java/jdk1.5.0_22/ ant clean jar -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7603: Application takes long time to fetch data from postgresql database
On 10/15/2012 10:54 PM, devenmtha...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 7603 Logged by: Deven Email address: devenmtha...@gmail.com PostgreSQL version: 9.0.3 Operating system: Windows 2003 R2 64 BITS Description: Hi, My application takes longer time (we see time out even) when data to be fetched from Postgresql 9.0.3 is around 190 records. I am doing an improvement at application level, but from database side any performance tuning do i need to do? This is not a bug report. See http://www.postgresql.org/docs/current/static/bug-reporting.html Please ask on the pgsql-general mailing list or on dba.stackexchange.com . Read this first: https://wiki.postgresql.org/wiki/Slow_Query_Questions Also, you're on a very old release in the 9.0 series. Update to 9.0.11 urgently. The Pg team doesn't release patches just for fun, they're released to fix bugs and security issues. See: http://www.postgresql.org/support/versioning/ http://www.postgresql.org/docs/9.0/static/release.html -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7602: Select with many joins against the same table is very slow compared to 9.2.0.
On 10/15/2012 06:55 PM, daniel.he...@sweco.se wrote: The following bug has been logged on the website: Bug reference: 7602 Logged by: Daniel Hedén Email address: daniel.he...@sweco.se PostgreSQL version: 9.2.1 Operating system: Windows 7 / Vista 64-Bit Description: Select with many joins against the same table is very slow compared to 9.2.0. In my case 16 times, this query takes a second max on 9.2.0 but on 9.2.1 it takes more than 30 minutes. Could you have accidentally reset `join_collapse_limit` to its default value? Show `EXPLAIN ANALYZE` output for both old and new cases, if possible. At least for the new one. (Please reply to the mailing list, not to me). -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6510: A simple prompt is displayed using wrong charset
On Mon, Oct 15, 2012 at 05:41:36AM -0400, Noah Misch wrote:
> > --- a/src/port/sprompt.c
> > +++ b/src/port/sprompt.c
> > @@ -60,8 +60,13 @@ simple_prompt(const char *prompt, int maxlen, bool echo)
> > * Do not try to collapse these into one "w+" mode file. Doesn't work on
> > * some platforms (eg, HPUX 10.20).
> > */
> > +#ifdef WIN32
> > + termin = fopen("CONIN$", "r");
> > + termout = fopen("CONOUT$", "w+");
>
> This definitely needs a block comment explaining the behaviors that led us to
> select this particular implementation.
>
> > +#else
> > termin = fopen(DEVTTY, "r");
> > termout = fopen(DEVTTY, "w");
>
> This thread has illustrated that the DEVTTY abstraction does not suffice. I
> think we should remove it entirely. Remove it from port.h; use literal
> "/dev/tty" here; re-add it as a local #define near the one remaining use, with
> an XXX comment indicating that the usage is broken.
>
> If it would help, I can prepare a version with the comment changes and
> refactoring I have in mind.
Following an off-list ack from Alexander, here is that version. No functional
differences from Alexander's latest version, and I have verified that it still
fixes the original test case. I'm marking this Ready for Committer.
To test this on an English (United States) copy of Windows 7, I made two
configuration changes in the "Region and Language" control panel. On the
"Administrative" tab, choose "Change system locale..." and select Russian
(Russia). After the reboot, choose "Russian (Russia)" on the "Format" tab.
(Neither of these changes will affect the display language of most Windows UI
components.) Finally, run "initdb -W testdatadir". Before the patch, the
password prompt contained some line-drawing characters and other garbage.
Afterward, it matches the string in src/bin/initdb/po/ru.po.
Thanks,
nm
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
***
*** 1043,1048 exec_command(const char *cmd,
--- 1043,1059
char *fname = psql_scan_slash_option(scan_state,
OT_NORMAL, NULL, true);
+ #if defined(WIN32) && !defined(__CYGWIN__)
+
+ /*
+* XXX This does not work for all terminal environments or for
output
+* containing non-ASCII characters; see comments in
simple_prompt().
+*/
+ #define DEVTTY"con"
+ #else
+ #define DEVTTY"/dev/tty"
+ #endif
+
expand_tilde(&fname);
/* This scrolls off the screen when using /dev/tty */
success = saveHistory(fname ? fname : DEVTTY, -1, false, false);
*** a/src/include/port.h
--- b/src/include/port.h
***
*** 110,120 extern BOOL AddUserToTokenDacl(HANDLE hToken);
#if defined(WIN32) && !defined(__CYGWIN__)
#define DEVNULL "nul"
- /* "con" does not work from the Msys 1.0.10 console (part of MinGW). */
- #define DEVTTY"con"
#else
#define DEVNULL "/dev/null"
- #define DEVTTY "/dev/tty"
#endif
/*
--- 110,117
*** a/src/port/sprompt.c
--- b/src/port/sprompt.c
***
*** 56,70 simple_prompt(const char *prompt, int maxlen, bool echo)
if (!destination)
return NULL;
/*
* Do not try to collapse these into one "w+" mode file. Doesn't work on
* some platforms (eg, HPUX 10.20).
*/
! 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
)
--- 56,97
if (!destination)
return NULL;
+ #ifdef WIN32
+
+ /*
+* A Windows console has an "input code page" and an "output code page";
+* these usually match each other, but they rarely match the "Windows
ANSI
+* code page" defined at system boot and expected of "char *" arguments
to
+* Windows API functions. The Microsoft CRT write() implementation
+* automatically converts text between these code pages when writing to
a
+* console. To identify such file descriptors, it calls
GetConsoleMode()
+* on the underlying HANDLE, which in turn requires GENERIC_READ access
on
+* the HANDLE. Opening termout in mode "w+" allows that detection to
+* succeed. Otherwise, write() would not recognize the descriptor as a
+* console, and non-ASCII characters would display incorrectly.
+*
+* XXX fgets() still receives text in the console's input code page.
This
+* makes non-ASCII credentials unportable.
+*/
+ termin = fopen("CONIN$", "r");
+ termout = fopen("CONOUT$", "w+");
+ #else
+
/*
* Do not try to collapse these into one "w+" mode file. Do
Re: [BUGS] pg_ctl restart issue with relative paths
On Sun, Oct 14, 2012 at 09:56:46AM -0700, Josh Kupershmidt wrote: > On Sat, Oct 13, 2012 at 3:56 PM, Thom Brown wrote: > > > I have noticed that, using pg_ctl, if you start Postgres using a > > relative path, then attempt to restart it from anywhere else, it > > fails. > > Yeah, I was complaining about the same problem here: > http://archives.postgresql.org/pgsql-bugs/2011-10/msg00210.php > > and at least there's a doc note now warning against using relative > paths, though it sure would be nice if we could fix this gripe. FYI, the doc patch is mentioned here: http://archives.postgresql.org/pgsql-bugs/2012-08/msg00133.php -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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 #7604: adding criteria to a query against a view in 9.2 expands the results instead of constraining them
Bill MacArthur writes: > Update, I started placing primary keys on the testcase tables and watched the > planner output. Once I put a PK on one of the tables in particular, the > planner revised the plan to use the PK. At that point, the results become > erroneous as the planner also moves another filter evaluation to an earlier > point at which time I don't think it has the data to make the decision. Curious ... > I can still finish up with the test case if you like, but here is a > highlight. The first VIEW, which I did not originally post is this: Test case, please. 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 #7604: adding criteria to a query against a view in 9.2 expands the results instead of constraining them
On 10/15/2012 2:29 PM, Tom Lane wrote: Bill MacArthur writes: Tom, in preparation for a test case I created a new schema (testcase) and copied 6 tables to that, including only the columns significant to enable the VIEWs to be created. I took the 3 VIEWs involved and tweaked them into the new schema (just renamed to testcase.viewname and referencing testcase.relation). However, when run from in there, the results are as expected rather than erroneous. The live data and VIEWs still produce erroneous results. Any clues?? Is the query plan the same according to EXPLAIN? If not, you may have forgotten to vacuum/analyze the new tables, or forgotten some relevant index. Or it might be that the total table size is affecting the plan choice, in which case you need dummy data in the "irrelevant" columns rather than removing them altogether. regards, tom lane Update, I started placing primary keys on the testcase tables and watched the planner output. Once I put a PK on one of the tables in particular, the planner revised the plan to use the PK. At that point, the results become erroneous as the planner also moves another filter evaluation to an earlier point at which time I don't think it has the data to make the decision. I can still finish up with the test case if you like, but here is a highlight. The first VIEW, which I did not originally post is this: CREATE OR REPLACE VIEW testcase.members_cancel_pending AS SELECT m.id, m.alias, m.emailaddress, m.firstname, m.lastname, m.mail_option_lvl, CASE WHEN c.id IS NULL THEN m.membertype WHEN c.status = 'tr'::text OR c.status = 'p'::text OR c.status = 'cd'::text OR c.status = 'sp'::text OR c.status = 'sa'::text THEN m.membertype ELSE 'c'::character varying END AS membertype FROM testcase.members m LEFT JOIN testcase.cancellations c ON c.id = m.id; The membertype column is actually calculated. Then I have the two VIEWs I previous posted: CREATE OR REPLACE VIEW testcase.vip_decline_mailers_base AS SELECT m.id, m.alias, m.firstname, m.lastname, m.emailaddress, CASE WHEN s.void = false THEN s.end_date ELSE (s.end_date - '1 mon'::interval)::date END AS paid_thru, mop.payment_method, m.mail_option_lvl, now()::date AS "current_date" FROM testcase.nop_seed, testcase.subscriptions s JOIN testcase.mop mop ON mop.id = s.member_id JOIN testcase.members_cancel_pending m ON m.id = s.member_id AND m.membertype::text = 'v'::text JOIN testcase.subscription_types st ON s.subscription_type = st.subscription_type WHERE (s.end_date < nop_seed.paid_thru OR s.void = true) AND st.sub_class::text = 'VM'::text; This should only be looking for membertype='v' From here another VIEW is built: CREATE OR REPLACE VIEW testcase.vip_mailer_unpaid_current AS SELECT vip_decline_mailers_base.id, vip_decline_mailers_base.alias, vip_decline_mailers_base.firstname, vip_decline_mailers_base.lastname, vip_decline_mailers_base.emailaddress, vip_decline_mailers_base.paid_thru, vip_decline_mailers_base.payment_method, vip_decline_mailers_base.mail_option_lvl, vip_decline_mailers_base."current_date", current_month_text(now()) AS current_month_text FROM testcase.vip_decline_mailers_base vip_decline_mailers_base WHERE vip_decline_mailers_base.mail_option_lvl > 0 AND vip_decline_mailers_base.paid_thru >= first_of_another_month((now()::date - '1 mon'::interval)::date) AND vip_decline_mailers_base.paid_thru <= (first_of_month() - 1); It is assuming that there will only be membertype 'v' is the basic results and is only applying date filters. Here is the planner output before I put a PK on testcase.cancellations network=# explain select count(*) from testcase.vip_mailer_unpaid_current; QUERY PLAN -- Aggregate (cost=29784.07..29784.08 rows=1 width=0) -> Nested Loop (cost=25947.06..29783.08 rows=395 width=0) Join Filter: ((s.end_date < nop_seed.paid_thru) OR s.void) -> Hash Right Join (cost=25947.06..29720.65 rows=1 width=5) Hash Cond: (c.id = m.id) Filter: ((CASE WHEN (c.id IS NULL) THEN m.membertype WHEN ((c.status = 'tr'::text) OR (c.status = 'p'::text) OR (c.status = 'cd'::text) OR (c.status = 'sp'::text) OR (c.status = 'sa'::text)) THEN m.membertype ELSE 'c'::char acter varying END)::text = 'v'::text) -> Seq Scan on
Re: [BUGS] BUG #7604: adding criteria to a query against a view in 9.2 expands the results instead of constraining them
Bill MacArthur writes: > Tom, in preparation for a test case I created a new schema (testcase) and > copied 6 tables to that, including only the columns significant to enable the > VIEWs to be created. I took the 3 VIEWs involved and tweaked them into the > new schema (just renamed to testcase.viewname and referencing > testcase.relation). However, when run from in there, the results are as > expected rather than erroneous. The live data and VIEWs still produce > erroneous results. Any clues?? Is the query plan the same according to EXPLAIN? If not, you may have forgotten to vacuum/analyze the new tables, or forgotten some relevant index. Or it might be that the total table size is affecting the plan choice, in which case you need dummy data in the "irrelevant" columns rather than removing them altogether. 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 #7604: adding criteria to a query against a view in 9.2 expands the results instead of constraining them
On 10/15/2012 12:18 PM, Tom Lane wrote: webmas...@dhs-club.com writes: vip_declines_mailers_base is another VIEW that merely adds some criteria to limit the result set of the 'base' VIEW. In versions 9.0 and back it did just that. After upgrading to 9.2, the criteria actually expand the result set. This doesn't seem to match any of the known bugs in 9.2, so I'm afraid there's no help for it: you need to create a self-contained test case. regards, tom lane Tom, in preparation for a test case I created a new schema (testcase) and copied 6 tables to that, including only the columns significant to enable the VIEWs to be created. I took the 3 VIEWs involved and tweaked them into the new schema (just renamed to testcase.viewname and referencing testcase.relation). However, when run from in there, the results are as expected rather than erroneous. The live data and VIEWs still produce erroneous results. Any clues?? -- 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 #7534: walreceiver takes long time to detect n/w breakdown
On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas wrote: > On 15.10.2012 13:13, Heikki Linnakangas wrote: >> >> On 13.10.2012 19:35, Fujii Masao wrote: >>> >>> ISTM you need to update the protocol.sgml because you added >>> the field 'replyRequested' to WalSndrMessage and StandbyReplyMessage. >> >> >> Oh, I didn't remember that we've documented the specific structs that we >> pass around. It's quite bogus anyway to explain the messages the way we >> do currently, as they are actually dependent on the underlying >> architecture's endianess and padding. I think we should refactor the >> protocol to not transmit raw structs, but use pq_sentint and friends to >> construct the messages. This was discussed earlier (see >> >> http://archives.postgresql.org/message-id/4fe2279c.2070...@enterprisedb.com), >> I think there's consensus that 9.3 would be a good time to do that as we >> changed the XLogRecPtr format anyway. > > > This is what I came up with. The replication protocol is now > architecture-independent. The WAL format itself is still > architecture-independent, of course, but this is useful if you want to e.g > use pg_receivexlog to back up a server that runs on a different platform. > > I chose the int64 format to transmit timestamps, even when compiled with > --disable-integer-datetimes. > > Please review if you have the time.. Thanks for the patch! When I ran pg_receivexlog, I encountered the following error. $ pg_receivexlog -D hoge pg_receivexlog: unexpected termination of replication stream: ERROR: no data left in message pg_basebackup -X stream caused the same error. $ pg_basebackup -D hoge -X stream -c fast pg_basebackup: could not send feedback packet: no COPY in progress pg_basebackup: child process exited with error 1 In walreceiver.c, tmpbuf is allocated for every XLogWalRcvProcessMsg() call. It should be allocated just once and continue to be used till end, to reduce palloc overhead? + hdrlen = sizeof(int64) + sizeof(int64) + sizeof(int64); + hdrlen = sizeof(int64) + sizeof(int64) + sizeof(char); These should be macro, to avoid calculation overhead? + /* Construct the the message and send it. */ + resetStringInfo(&reply_message); + pq_sendbyte(&reply_message, 'h'); + pq_sendint(&reply_message, xmin, 4); + pq_sendint(&reply_message, nextEpoch, 4); + walrcv_send(reply_message.data, reply_message.len); You seem to have forgotten to send the sendTime. Regards, -- Fujii Masao -- 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 #7604: adding criteria to a query against a view in 9.2 expands the results instead of constraining them
webmas...@dhs-club.com writes: > vip_declines_mailers_base is another VIEW that merely adds some criteria to > limit the result set of the 'base' VIEW. In versions 9.0 and back it did > just that. After upgrading to 9.2, the criteria actually expand the result > set. This doesn't seem to match any of the known bugs in 9.2, so I'm afraid there's no help for it: you need to create a self-contained test case. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7604: adding criteria to a query against a view in 9.2 expands the results instead of constraining them
The following bug has been logged on the website: Bug reference: 7604 Logged by: Bill MacArthur Email address: webmas...@dhs-club.com PostgreSQL version: 9.2.1 Operating system: CentOS 5.8 Description: vip_declines_mailers_base is a VIEW that itself uses another VIEW alongside several other joined tables. nop_seed is a 1 column table that contains 1 date as a reference. members_cancel_pending is a VIEW. CREATE OR REPLACE VIEW vip_decline_mailers_base AS SELECT m.id, m.alias, m.firstname, m.lastname, m.emailaddress, CASE WHEN s.void = false THEN s.end_date ELSE (s.end_date - '1 mon'::interval)::date END AS paid_thru, mop.payment_method, m.mail_option_lvl, now()::date AS "current_date" FROM nop_seed, subscriptions s JOIN mop ON mop.id = s.member_id JOIN members_cancel_pending m ON m.id = s.member_id AND m.membertype::text = 'v'::text JOIN subscription_types st ON s.subscription_type = st.subscription_type WHERE (s.end_date < nop_seed.paid_thru OR s.void = true) AND st.sub_class::text = 'VM'::text; Then executing a query against vip_declines_mailers_base with no constraining arguments, the complete result set counts as this: network=# select count(*) from vip_decline_mailers_base; count --- 358 vip_declines_mailers_base is another VIEW that merely adds some criteria to limit the result set of the 'base' VIEW. In versions 9.0 and back it did just that. After upgrading to 9.2, the criteria actually expand the result set. CREATE OR REPLACE VIEW vip_mailer_unpaid_current AS SELECT vip_decline_mailers_base.id, vip_decline_mailers_base.alias, vip_decline_mailers_base.firstname, vip_decline_mailers_base.lastname, vip_decline_mailers_base.emailaddress, vip_decline_mailers_base.paid_thru, vip_decline_mailers_base.payment_method, vip_decline_mailers_base.mail_option_lvl, vip_decline_mailers_base."current_date", current_month_text(now()) AS current_month_text FROM vip_decline_mailers_base WHERE vip_decline_mailers_base.mail_option_lvl > 0 AND vip_decline_mailers_base.paid_thru >= first_of_another_month((now()::date - '1 mon'::interval)::date) AND vip_decline_mailers_base.paid_thru <= (first_of_month() - 1); network=# select count(*) from vip_mailer_unpaid_current; count --- 391 How can this be? What's worse, is that adding the criteria somehow mangles the inner workings of the 'base' VIEW and causes it to return results where the membertype does not even match the join criteria which should be 'v' only. I could create a self contained test case, but the number of tables and scrubbing the data could be tedious. Perhaps there is enough here to help pinpoint a trouble spot. I should restate, also, that these VIEWS have been working fine with 9.0 and earlier versions. FWIW, here are the EXPLAINs on the two queries. network=# explain select count(*) from vip_decline_mailers_base; QUERY PLAN -- Aggregate (cost=82439.33..82439.34 rows=1 width=0) -> Hash Right Join (cost=78647.01..82439.21 rows=47 width=0) Hash Cond: (c.id = m.id) Filter: ((CASE WHEN (c.id IS NULL) THEN m.membertype WHEN ((c.status = 'tr'::text) OR (c.status = 'p'::text) OR (c.status = 'cd'::text) OR (c.status = 'sp'::text) OR (c.status = 'sa'::text)) THEN m.membertype ELSE 'c'::character varying END)::text = 'v'::text) -> Seq Scan on cancellations c (cost=0.00..3325.35 rows=119735 width=6) -> Hash (cost=78529.91..78529.91 rows=9368 width=6) -> Hash Join (cost=6128.57..78529.91 rows=9368 width=6) Hash Cond: (m.id = mop.id) -> Seq Scan on members m (cost=0.00..66417.39 rows=1570739 width=6) -> Hash (cost=6011.47..6011.47 rows=9368 width=8) -> Hash Join (cost=3129.39..6011.47 rows=9368 width=8) Hash Cond: (mop.id = s.member_id) -> Seq Scan on mop (cost=0.00..2158.67 rows=71967 width=4) -> Hash (cost=3012.28..3012.28 rows=9369 width=4) -> Nested Loop (cost=2.67..3012.28 rows=9369 width=4) Join Filter: ((s.end_date < nop_seed.paid_thru) OR s.void) -> Seq Scan on nop_seed (cost=0.00..1.01 rows=1 width=4) -> Hash Join (cost=2.67..2723.56 rows=23017 width=9)
Re: [BUGS] BUG #7598: Loss of view performance after dump/restore of the view definition
Vaclav Juza writes: > I have modified the test case (it is more similar to the real-word > query), so that now it is slower on 9.2.1 than on 9.1.4 (the version > with the explicit cast): FWIW, testing this on HEAD (with the patch I committed last week), I get a plan that's about 10% faster than 9.1; or if I disable index-only scans for a more level playing field, it's just about equivalent to 9.1. 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 #7577: JDBC Driver - Compiled with Java 7
To add to this, it's not just a question of making more sense. Compiling the code with Java 7 means the generated class files are version 51, which is not acceptable to a Java 5 JRE - it wants version 49. So the existing pre-built jar cannot simply be dropped into a Java 5 app. To get around this I'm trying to build from source without much more success. When I follow the recommendation of using a 1.5 JDK, for some reason ant still craps out with an UnsupportedClassVersionError. I also tried to hack the build.xml to force compilation with source="1.5" and target="1.5", but then the compilation fails like this: compile: [javac] /opt/sean/software/postgresql-jdbc-9.0-802.src/build.xml:120: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Compiling 176 source files to /opt/sean/software/postgresql-jdbc-9.0-802.src/build [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.5 [javac] /opt/sean/software/postgresql-jdbc-9.0-802.src/org/postgresql/Driver.java:47: error: org.postgresql.Driver is not abstract and does not override abstract method getParentLogger() in java.sql.Driver [javac] public class Driver implements java.sql.Driver [javac]^ [javac] /opt/sean/software/postgresql-jdbc-9.0-802.src/org/postgresql/ds/PGConnectionPoolDataSource.java:39: error: PGConnectionPoolDataSource is not abstract and does not override abstract method getParentLogger() in CommonDataSource [javac] public class PGConnectionPoolDataSource extends BaseDataSource implements Serializable, ConnectionPoolDataSource [javac]^ [javac] /opt/sean/software/postgresql-jdbc-9.0-802.src/org/postgresql/ds/PGPooledConnection.java:26: error: PGPooledConnection is not abstract and does not override abstract method removeStatementEventListener(StatementEventListener) in PooledConnection etc. Does anyone have a solution for people like me who must use Java 5? Thanks, Sean -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-7577-JDBC-Driver-Compiled-with-Java-7-tp5726254p5728220.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 #7592: Installation of PostGresql at c:\Progam files folder does not create right permission on data folder
Thanks craig, Since we got response from other community guys that i have to upgrade to 9.0.10 to resolve this issue. Since many permission related issues have been fixed till this release. So planning to upgrade to 9.0.10. Regards Deven On Sun, Oct 14, 2012 at 11:19 AM, Craig Ringer wrote: > On 10/10/2012 01:07 PM, devenmtha...@gmail.com wrote: > >> The following bug has been logged on the website: >> >> Bug reference: 7592 >> Logged by: Deven >> Email address: devenmtha...@gmail.com >> PostgreSQL version: 9.0.3 >> Operating system: Windows 2008 R2 WITH SP1 (64 BITS) >> Description: >> >> We are installing our application which internally call >> postgresql-9.0.3-2-windows_**x64.exe to install postgresql under >> c:\program >> files folder. But initialization of datbase failed with log that >> user(administrator) does not have enough permission on data folder. >> Can anyone help me out to address this issue? >> > > That's odd. Is it only on one computer? Or have you tried it on several > different computers with the same results? > > Does the error persist if you run the installer with the same command line > directly, not via your installer? > > Can you show the installer log file? > > What happens if you use a current installer - at least 9.0.10, preferably > 9.2.1. > > -- > Craig Ringer >
[BUGS] Fetching large no of data takes lot of time
Hi, My application takes longer time (we see time out even) when data to be fetched from Postgresql 9.0.3 is around 190 records. I am doing an improvement at application level, but from database side any performance tuning do i need to do? I have not changed any parameters in postgresql.conf, so using default values. My PC has RAM of 4 GB (Windows 2003 R2 64 BITS) Regards Deven
[BUGS] BUG #7603: Application takes long time to fetch data from postgresql database
The following bug has been logged on the website: Bug reference: 7603 Logged by: Deven Email address: devenmtha...@gmail.com PostgreSQL version: 9.0.3 Operating system: Windows 2003 R2 64 BITS Description: Hi, My application takes longer time (we see time out even) when data to be fetched from Postgresql 9.0.3 is around 190 records. I am doing an improvement at application level, but from database side any performance tuning do i need to do? I have not changed any parameters in postgresql.conf, using default values. My PC has RAM of 4 GB. -- 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 #7600: Database crash with data corruption
On Mon, Oct 15, 2012 at 3:31 PM, Craig Ringer wrote: > > OK, that sounds more like a problem. It wasn't clear from your original > post that it was replaying used sequence values. > > SIGINT should normally just terminate the statement, eg: > > regress=# SELECT pg_sleep(100); > ERROR: canceling statement due to user request > > so I agree that something isn't right here. > > Is this something you've been able to reproduce? Or is it a one-off > incident so far? > > -- > Craig Ringer > > It is just one-off incident. We have increased sequences values and since friday everything is running fine. We haven't tried to reproduce this situation. Michał Hankiewicz
[BUGS] BUG #7602: Select with many joins against the same table is very slow compared to 9.2.0.
The following bug has been logged on the website: Bug reference: 7602 Logged by: Daniel Hedén Email address: daniel.he...@sweco.se PostgreSQL version: 9.2.1 Operating system: Windows 7 / Vista 64-Bit Description: Select with many joins against the same table is very slow compared to 9.2.0. In my case 16 times, this query takes a second max on 9.2.0 but on 9.2.1 it takes more than 30 minutes. The database is the same in both cases and running analyze does not help. On request i could send the SQL and a database backup. -- 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 #7600: Database crash with data corruption
You misunderstand me. According to the server logs I have sent in the first message process received signal 2 (it is SIGINT) and according to the documentation this signal should not couse server crash. Wrong values of sequences does not mean hole in generated values, but sequence started to generate the same values once again causing unique constraint violation. regards Michał Hankiewicz On Sat, Oct 13, 2012 at 1:10 PM, Craig Ringer wrote: > On 10/12/2012 09:35 PM, hankiew...@gmail.com wrote: > >> 5) after recovery was completed we have discovered that sequences on >> production database had wrong values >> > > To follow up on Tom's explanation, if you're relying on sequences not > having "holes" then your design is dangerously mistaken. A simple ROLLBACK > throws away any IDs that were obtained from sequences in that transaction. > > If you're saying that the sequence is wrong in that it's LOWER than IDs > present in the table, then that's a problem. > > -- > Craig Ringer >
Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
On 15.10.2012 13:13, Heikki Linnakangas wrote: On 13.10.2012 19:35, Fujii Masao wrote: ISTM you need to update the protocol.sgml because you added the field 'replyRequested' to WalSndrMessage and StandbyReplyMessage. Oh, I didn't remember that we've documented the specific structs that we pass around. It's quite bogus anyway to explain the messages the way we do currently, as they are actually dependent on the underlying architecture's endianess and padding. I think we should refactor the protocol to not transmit raw structs, but use pq_sentint and friends to construct the messages. This was discussed earlier (see http://archives.postgresql.org/message-id/4fe2279c.2070...@enterprisedb.com), I think there's consensus that 9.3 would be a good time to do that as we changed the XLogRecPtr format anyway. This is what I came up with. The replication protocol is now architecture-independent. The WAL format itself is still architecture-independent, of course, but this is useful if you want to e.g use pg_receivexlog to back up a server that runs on a different platform. I chose the int64 format to transmit timestamps, even when compiled with --disable-integer-datetimes. Please review if you have the time.. - Heikki diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml index 3d72a16..5a32517 100644 --- a/doc/src/sgml/protocol.sgml +++ b/doc/src/sgml/protocol.sgml @@ -1366,7 +1366,8 @@ The commands accepted in walsender mode are: WAL data is sent as a series of CopyData messages. (This allows other information to be intermixed; in particular the server can send an ErrorResponse message if it encounters a failure after beginning - to stream.) The payload in each CopyData message follows this format: + to stream.) The payload of each CopyData message from server to the + client contains a message of one of the following formats: @@ -1390,34 +1391,32 @@ The commands accepted in walsender mode are: - Byte8 + Int64 - The starting point of the WAL data in this message, given in - XLogRecPtr format. + The starting point of the WAL data in this message. - Byte8 + Int64 - The current end of WAL on the server, given in - XLogRecPtr format. + The current end of WAL on the server. - Byte8 + Int64 - The server's system clock at the time of transmission, - given in TimestampTz format. + The server's system clock at the time of transmission, as + microseconds since midnight on 2000-01-01. @@ -1445,25 +1444,12 @@ The commands accepted in walsender mode are: continuation records can be sent in different CopyData messages. - Note that all fields within the WAL data and the above-described header - will be in the sending server's native format. Endianness, and the - format for the timestamp, are unpredictable unless the receiver has - verified that the sender's system identifier matches its own - pg_control contents. - - If the WAL sender process is terminated normally (during postmaster shutdown), it will send a CommandComplete message before exiting. This might not happen during an abnormal shutdown, of course. - The receiving process can send replies back to the sender at any time, - using one of the following message formats (also in the payload of a - CopyData message): - - - @@ -1495,12 +1481,23 @@ The commands accepted in walsender mode are: - Byte8 + Int64 - The server's system clock at the time of transmission, - given in TimestampTz format. + The server's system clock at the time of transmission, as + microseconds since midnight on 2000-01-01. + + + + + + Byte1 + + + + 1 means that the client should reply to this message as soon as + possible, to avoid a timeout disconnect. 0 otherwise. @@ -1512,6 +1509,12 @@ The commands accepted in walsender mode are: + The receiving process can send replies back to the sender at any time, + using one of the following message formats (also in the payload of a + CopyData message): + + + @@ -1532,45 +1535,56 @@ The commands accepted in walsender mode are: - Byte8 + Int64 The location of the last WAL byte + 1 received and written to disk - in the standby, in XLogRecPtr f
Re: [BUGS] BUG #7600: Database crash with data corruption
On 10/15/2012 04:17 PM, Michał Hankiewicz wrote: You misunderstand me. According to the server logs I have sent in the first message process received signal 2 (it is SIGINT) and according to the documentation this signal should not couse server crash. Wrong values of sequences does not mean hole in generated values, but sequence started to generate the same values once again causing unique constraint violation. OK, that sounds more like a problem. It wasn't clear from your original post that it was replaying used sequence values. SIGINT should normally just terminate the statement, eg: regress=# SELECT pg_sleep(100); ERROR: canceling statement due to user request so I agree that something isn't right here. Is this something you've been able to reproduce? Or is it a one-off incident so far? -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7598: Loss of view performance after dump/restore of the view definition
On 12/10/2012 23:24, Tom Lane wrote:
> vaclav.j...@xitee.com writes:
>
>> In the real case we faced this problem, the performance loss was much higher
>> on PostgreSQL 9.2.1 (3 seconds vs. 3 minutes) than on 9.1.4 (1.3 seconds vs.
>> 7 seconds) and both variants were slower on 9.2.1 than on 9.1.4. In the test
>> case below the behaviour is similar on both Postgres version.
>
> It's difficult to tell whether there's any real issue here beyond that.
> I sometimes get a noticeably slower plan out of HEAD, but sometimes I
> don't, if I regenerate the random table contents. It looks to me like
> the slower plans occur when it changes the join ordering, but that's
> contingent on rowcount estimates that are equally awful in both versions;
> the lvl = (SELECT max/min(lvl) ...) conditions are not estimated well by
> any existing Postgres release. So I'm not inclined to ascribe a lot of
> significance to the planner's choices here.
>
> regards, tom lane
>
Hi,
I have modified the test case (it is more similar to the real-word
query), so that now it is slower on 9.2.1 than on 9.1.4 (the version
with the explicit cast):
Setup took cca 230s on my hw:
== BEGIN TEST SETUP =
set search_path=public, pg_catalog;
create table testtable1
(
ida character varying (10), idb character varying (10), idc character
varying (10),
idd character varying (10),
lvl numeric, parname character varying (10), val numeric
);
alter table testtable1 add constraint pk_testtable1 primary key (ida,
idb, idc, idd, parname, lvl);
create table testtable2
(
ida character varying (10), idb character varying (10), idc character
varying (10),
lvl numeric, parname character varying (10), val numeric
);
alter table testtable2 add constraint pk_testtable2 primary key (ida,
idb, idc, parname, lvl);
create table testtable3
(
ida character varying (10),
idd character varying (10),
status character(1)
);
alter table testtable3 add constraint pk_testtable3 primary key (ida, idd);
create table testtable4
(
ida character varying (10), idb character varying (10), idc character
varying (10),
detail character varying (100)
);
alter table testtable4 add constraint pk_testtable4 primary key (ida,
idb, idc);
insert into testtable1
select
'a' || a.a, 'bb' || b.b, 'ccc' || c.c, '' || d.d,
(37*a.a + 53*b.b + 71*5*c.c + 101*3*lvl.lvl) % 512,
'PARNAME' || p.p,
(31*a.a + 17*b.b + 7*5*c.c + 11*3*lvl.lvl) % 2
from
generate_series(1, 5) a, generate_series(1, 50) b, generate_series(1,
100) c,
generate_series(1, 3) d, generate_series(1, 3) lvl, generate_series(1,
4) p;
insert into testtable2
select
'a' || a.a, 'bb' || b.b, 'ccc' || 5*c.c,
(37*a.a + 53*b.b + 71*2*c.c + 101*lvl.lvl) % 512,
'PARNAME' || p.p,
(31*a.a + 17*b.b + 7*2*c.c + 11*lvl.lvl) % 8
from generate_series(1, 5) a, generate_series(1, 50) b,
generate_series(1, 250) c,
generate_series(1, 6) lvl, generate_series(1, 6) p;
insert into testtable3
select
'a' || a.a, '' || d.d,
chr(ascii('A') + (31*a.a + 17*d.d) % 2)
from generate_series(1, 5) a, generate_series(1, 10) d;
insert into testtable4
select
'a' || a.a, 'bb' || b.b, 'ccc' || 5*c.c,
'some_comment' || a.a || b.b
from generate_series(1, 5) a, generate_series(1, 50) b,
generate_series(1, 250) c;
create or replace view testview as
select ida, idb, idc, idd, lvl, parname, val
from (
SELECT tt1.ida, tt1.idb, tt1.idc, tt1.idd, tt1.lvl, tt1.parname, tt1.val
FROM testtable1 tt1
JOIN
( SELECT tt2.ida, tt2.idb, tt2.idc, tt2.lvl, tt2.parname
FROM testtable2 tt2
JOIN testtable4 tt4 ON tt4.ida = tt2.ida AND tt4.idb = tt2.idb
AND tt4.idc = tt2.idc
WHERE tt2.lvl =
( SELECT max(tt2a.lvl) AS max
FROM testtable2 tt2a
WHERE tt2.ida = tt2a.ida
AND tt2.idb = tt2a.idb
AND tt2.idc = tt2a.idc
AND tt2a.lvl <= 400
)
) ip ON ip.ida = tt1.ida AND ip.idb = tt1.idb
AND ip.idc = tt1.idc
JOIN testtable3 tt3 ON tt3.ida = tt1.ida AND tt3.idd = tt1.idd
AND tt3.status = 'A'
WHERE tt1.lvl =
(
( SELECT max(tt1a.lvl) AS max
FROM testtable1 tt1a
WHERE tt1.ida = tt1a.ida AND tt1.idb = tt1a.idb
AND tt1.idc = tt1a.idc AND tt1.idd = tt1a.idd
AND tt1.parname = tt1a.parname AND tt1a.lvl <= 400
)
)
) a
where (ida, idb, idc, idd)
in
(
select ida, idb, idc, idd
from
(
SELECT tt1.ida, tt1.idb, tt1.idc, tt1.idd, tt1.lvl, tt1.parname,
tt1.val
FROM testtable1 tt1
JOIN
( SELECT tt2.ida, tt2.idb, tt2.idc, tt2.lvl, tt2.parname
FROM testtable2 tt2
JOIN testtable4 tt4 ON tt4.ida = tt2.ida AND tt4.idb =
tt2.idb AND tt4.idc = tt2.idc
WHERE tt2.lvl =
( SELECT max(tt2a.lvl) AS max
FROM testtable2 tt2a
WHERE tt2.ida = tt2a.ida
AND tt2.idb = tt2a.idb
AND tt2.idc = tt2a.idc
[BUGS] builded Installer is not work.
At first week, I can `t even compile. But now I compiled it without errors. Then I built the installer. But during installation there is an error. Library not loaded. I want to get a full cycle from compile to install. I need my own distribution. I need my own installer. I tried to do it on VS6 VS2003 VS2005. My DLL's built differ from DLL's from you installer (ftp://ftp.postgresql.org/pub/odbc/versions/msi/psqlodbc_09_01_0200-x64.zip). I compile: **C:\odbc\64\psqlodbc-09.01.0200>*nmake /f win64.mak CFG=Release ALL USE_LIBPQ=yes PG_INC=c:\PostgreSQL\9.1_x64\include PG_LIB=c:\PostgreSQL\9.1_x64\lib SSL_INC=c:\OpenSSL-Win64\include SSL_LIB=c:\OpenSSL-Win64\lib\VC\ CPU=AMD64 ***C:\odbc\64\psqlodbc-09.01.0200>*nmake /f win64.mak CFG=Release ALL USE_LIBPQ=yes ANSI_VERSION=yes PG_INC=c:\PostgreSQL\9.1_x64\include PG_LIB=c:\PostgreSQL\9.1_x64\lib SSL_INC=c:\OpenSSL-Win64\include SSL_LIB=c:\OpenSSL-Win64\lib\VC\ CPU=AMD64 ** * ... Then i build installer: *cd installer** ** **C:\odbc\64\psqlodbc-09.01.0200\installer>MakeX64.bat** **para=""** **LIBPQBINDIR=** **wix_dir="C:\Program Files (x86)\WiX Toolset v3.6\bin"** ** **Version not specified - defaulting to "09.01.0200"** ** **Building psqlODBC merge module...** **psqlodbcm_cpu.wxs** **Linking psqlODBC merge module...** ** **Building psqlODBC installer database...** **psqlodbc_cpu.wxs** **Linking psqlODBC installer database...** ** **Modifying psqlODBC installer database...** **Microsoft (R) Windows Script Host Version 5.8** **Copyright (C) Microsoft Corporation. All rights reserved.** ** **dyoqjjp5.dll|psqlodbc30a.dll -> psqlodbc30a.dll** **pmlis0nk.dll|psqlodbc35w.dll -> psqlodbc35w.dll** ** **Done** * and then I try Installed: * C:\odbc\64\psqlodbc-09.01.0200\installer>cd x64 C:\odbc\64\psqlodbc-09.01.0200\installer\x64>psqlodbc_x64.msi* During installation I get an error. I can not understand why this error occurs. Error 1918. Error installing ODBC driver: PostgreSQL ANSI(x64), ODBC error 13: The setup routines for the PostgreSQL ANSI(x64) ODBC driver could not be loaded due to system error code 126: The specified module could not be found. (C:\psqlODBC\0901\bin\psqlodbc30a.dll).. Verify that the file PostgreSQL ANSI(x64) exists and that you can access it. >>so you just need to compile the driver for Windows x64? The exact compiler version isn't actually the concern, it's just that you need help with >>compiling it? Yes, if it is possible >> Hang on, so you can compile it fine, but you're having trouble creating an *installer* for it? Yes / //PS. Sorry for my bad english/ 14.10.2012 19:45, Craig Ringer пишет: On 10/14/2012 09:40 PM, Копыченко Павел wrote: Still, thank you very much for your response. I can `t have two weeks to build the driver from source for Windows 7 x64. ... so you just need to compile the driver for Windows x64? The exact compiler version isn't actually the concern, it's just that you need help with compiling it? But this error is repeated. I beg you to help me. I really need my version driver. Hang on, so you can compile it fine, but you're having trouble creating an *installer* for it? -- Craig Ringer
Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
On 13.10.2012 19:35, Fujii Masao wrote: On Thu, Oct 11, 2012 at 11:52 PM, Heikki Linnakangas wrote: Ok, thanks. Committed. I found one typo. The attached patch fixes that typo. Thanks, fixed. ISTM you need to update the protocol.sgml because you added the field 'replyRequested' to WalSndrMessage and StandbyReplyMessage. Oh, I didn't remember that we've documented the specific structs that we pass around. It's quite bogus anyway to explain the messages the way we do currently, as they are actually dependent on the underlying architecture's endianess and padding. I think we should refactor the protocol to not transmit raw structs, but use pq_sentint and friends to construct the messages. This was discussed earlier (see http://archives.postgresql.org/message-id/4fe2279c.2070...@enterprisedb.com), I think there's consensus that 9.3 would be a good time to do that as we changed the XLogRecPtr format anyway. I'll look into doing that.. Is it worth adding the same mechanism (send back the reply immediately if walsender request a reply) into pg_basebackup and pg_receivexlog? Good catch. Yes, they should be taught about this too. I'll look into doing that too. - Heikki -- 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 #6510: A simple prompt is displayed using wrong charset
On Sun, Oct 14, 2012 at 12:10:42PM -0400, Tom Lane wrote:
> Alexander Law writes:
>
> > +#ifdef WIN32
> > + termin = fopen("CONIN$", "r");
> > + termout = fopen("CONOUT$", "w+");
> > +#else
> > termin = fopen(DEVTTY, "r");
> > termout = fopen(DEVTTY, "w");
> > +#endif
> > if (!termin || !termout
>
> My immediate reaction to this patch is "that's a horrible kluge, why
> shouldn't we change the definition of DEVTTY instead?"
You could make DEVTTY_IN, DEVTTY_IN_MODE, DEVTTY_OUT and DEVTTY_OUT_MODE to
capture all the differences. That doesn't strike me as an improvement, and no
other function would use them at present. As I explained in my reply to
Alexander, we should instead remove DEVTTY.
> Is there a
> similar issue in other places where we use DEVTTY?
Yes. However, the other use of DEVTTY arises only with readline support, not
typical of native Windows builds.
> Also, why did you change the termout output mode, is that important
> or just randomness?
It's essential:
http://archives.postgresql.org/message-id/20121010110555.ga21...@tornado.leadboat.com
nm
--
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 #6510: A simple prompt is displayed using wrong charset
On Sun, Oct 14, 2012 at 10:35:04AM +0400, Alexander Law wrote:
> I agree with you, CONOUT$ way is much simpler. Please look at the patch.
See comments below.
> Regarding msys - yes, that check was not correct.
> In fact you can use "con" with msys, if you run sh.exe, not a graphical
> terminal.
> So the issue with con not related to msys, but to some terminal
> implementations.
> Namely, I see that con is not supported by rxvt, mintty and xterm (from
> x.cygwin project).
> (rxvt was default terminal for msys 1.0.10, so I think such behavior was
> considered as msys feature because of this)
> Your solution to use IsWindowVisible(GetConsoleWindow()) works for these
> terminals (I've made simple test and it returns false for all of them),
> but this check will not work for telnet (console app running through
> telnet can use con/conout).
Thanks for testing those environments. I can reproduce the distinctive
behavior when a Windows telnet client connects to a Windows telnet server.
When I connect to a Windows telnet server from a GNU/Linux system, I get the
normal invisible-console behavior.
I also get the invisible-console behavior in PowerShell ISE.
> Maybe this should be considered as a distinct bug with another patch
> required? (I see no ideal solution for it yet. Probably it's possible to
> detect not "ostype", but these terminals, though it would not be generic
> too.)
Using stdin/stderr when we could have used the console is a mild loss; use
cases involving redirected output will need to account for the abnormality.
Interacting with a user-invisible console is a large loss; prompts will hang
indefinitely. Therefore, the test should err on the side of stdin/stderr.
Since any change here seems to have its own trade-offs, yes, let's leave it
for a separate patch.
> And there is another issue with a console charset. When writing string
> to a console CRT converts it to console encoding, but when reading input
> back it doesn't. So it seems, there should be conversion from
> ConsoleCP() to ACP() and then probably to UTF-8 to make postgres
> utilities support national chars in passwords or usernames (with
> createuser --interactive).
Yes, that also deserves attention. I do not know whether converting to UTF-8
is correct. Given a username containing non-ASCII characters, you
should be able to input the same way for both "psql -U " and the
createuser prompt. We should also be thoughtful about backward compatibility.
> I think it can be fixed as another bug too.
Agreed.
> --- a/src/port/sprompt.c
> +++ b/src/port/sprompt.c
> @@ -60,8 +60,13 @@ simple_prompt(const char *prompt, int maxlen, bool echo)
>* Do not try to collapse these into one "w+" mode file. Doesn't work on
>* some platforms (eg, HPUX 10.20).
>*/
> +#ifdef WIN32
> + termin = fopen("CONIN$", "r");
> + termout = fopen("CONOUT$", "w+");
This definitely needs a block comment explaining the behaviors that led us to
select this particular implementation.
> +#else
> termin = fopen(DEVTTY, "r");
> termout = fopen(DEVTTY, "w");
This thread has illustrated that the DEVTTY abstraction does not suffice. I
think we should remove it entirely. Remove it from port.h; use literal
"/dev/tty" here; re-add it as a local #define near the one remaining use, with
an XXX comment indicating that the usage is broken.
If it would help, I can prepare a version with the comment changes and
refactoring I have in mind.
> +#endif
> if (!termin || !termout
> #ifdef WIN32
> /* See DEVTTY comment for msys */
Thanks,
nm
--
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] Fwd: race in pg_ctl start -w
On 11.10.2012 22:36, Tom Lane wrote: Heikki Linnakangas writes: Hmm, starting with 9.3, postmaster can not only create and append to the end of file, it can also inject a line in the middle, shifting the following lines forwards. In theory, if a new line is injected into the middle of the file between fgets() calls, readfile() could read part of the same line twice. Not sure what consequences that could have; pg_ctl might try to connect to wrong address or socket directory. Hm. IIRC, the postmaster is careful to write the whole thing in a single write() call, which in principle is atomic. Perhaps you're right that we'd better have pg_ctl read it in a single read() to ensure that it sees a consistent file state. Otherwise we're making assumptions about what sort of buffering underlies the stdio functions. Ok, changed it to slurp the whole file to memory with one read() call. Dave, did this silence the static analysis tool you used? - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
