[BUGS] BUG #7612: Wrong result with join between two values () set
The following bug has been logged on the website: Bug reference: 7612 Logged by: Maxim Boguk Email address: maxim.bo...@gmail.com PostgreSQL version: 9.2.1 Operating system: Linux Description: Join between two values() set could produce wrong results: Test case: Correct answer: SELECT a.val, b.val FROM (VALUES( (2), (1) )) AS a (val) JOIN (VALUES( (2), (42) )) AS b (val) ON a.val = b.val; val | val -+- 2 | 2 (1 row) now just change position of (2) and (1) in a(val): Wrong answer: SELECT a.val, b.val FROM (VALUES( (1), (2) )) AS a (val) JOIN (VALUES( (2), (42) )) AS b (val) ON a.val = b.val; val | val -+- (0 rows) explain (analyze, verbose) results of the both queries: mboguk=# explain (analyze, verbose) SELECT a.val, b.val FROM (VALUES( (2), (1) )) AS a (val) JOIN (VALUES( (2), (42) )) AS b (val) ON a.val = b.val; QUERY PLAN - Nested Loop (cost=0.00..0.04 rows=1 width=8) (actual time=0.070..0.118 rows=1 loops=1) Output: *VALUES*.column1, *VALUES*.column1 Join Filter: (*VALUES*.column1 = *VALUES*.column1) - Values Scan on *VALUES* (cost=0.00..0.01 rows=1 width=4) (actual time=0.016..0.027 rows=1 loops=1) Output: *VALUES*.column1, *VALUES*.column2 - Values Scan on *VALUES* (cost=0.00..0.01 rows=1 width=4) (actual time=0.013..0.024 rows=1 loops=1) Output: *VALUES*.column1, *VALUES*.column2 Total runtime: 0.209 ms (8 rows) mboguk=# explain (analyze, verbose) SELECT a.val, b.val FROM (VALUES( (1), (2) )) AS a (val) JOIN (VALUES( (2), (42) )) AS b (val) ON a.val = b.val; QUERY PLAN - Nested Loop (cost=0.00..0.04 rows=1 width=8) (actual time=0.056..0.056 rows=0 loops=1) Output: *VALUES*.column1, *VALUES*.column1 Join Filter: (*VALUES*.column1 = *VALUES*.column1) Rows Removed by Join Filter: 1 - Values Scan on *VALUES* (cost=0.00..0.01 rows=1 width=4) (actual time=0.008..0.013 rows=1 loops=1) Output: *VALUES*.column1, *VALUES*.column2 - Values Scan on *VALUES* (cost=0.00..0.01 rows=1 width=4) (actual time=0.007..0.013 rows=1 loops=1) Output: *VALUES*.column1, *VALUES*.column2 Total runtime: 0.100 ms (9 rows) -- 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
Noah Misch escribió: 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. This seems good to me, but I'm not comfortable committing Windows stuff. Andrew, Magnus, are you able to handle this? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- 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 #7612: Wrong result with join between two values () set
On Thu, Oct 18, 2012 at 5:40 PM, maxim.bo...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 7612 Logged by: Maxim Boguk Email address: maxim.bo...@gmail.com PostgreSQL version: 9.2.1 Operating system: Linux Description: Join between two values() set could produce wrong results: This is not a bug; your test case produces correct results. Your VALUES clauses are producing one row with two columns each called val and column2. You are joining on val and so when you switch the values to put 2 in different columns, no results are found. Is it possible you didn't intend to put the parentheses immediately following the VALUES keyword? I think that is the case because your parentheses around the numbers are superfluous. Test case: Correct answer: SELECT a.val, b.val FROM (VALUES( (2), (1) )) AS a (val) JOIN (VALUES( (2), (42) )) AS b (val) ON a.val = b.val; val | val -+- 2 | 2 (1 row) now just change position of (2) and (1) in a(val): Wrong answer: SELECT a.val, b.val FROM (VALUES( (1), (2) )) AS a (val) JOIN (VALUES( (2), (42) )) AS b (val) ON a.val = b.val; val | val -+- (0 rows) explain (analyze, verbose) results of the both queries: mboguk=# explain (analyze, verbose) SELECT a.val, b.val FROM (VALUES( (2), (1) )) AS a (val) JOIN (VALUES( (2), (42) )) AS b (val) ON a.val = b.val; QUERY PLAN - Nested Loop (cost=0.00..0.04 rows=1 width=8) (actual time=0.070..0.118 rows=1 loops=1) Output: *VALUES*.column1, *VALUES*.column1 Join Filter: (*VALUES*.column1 = *VALUES*.column1) - Values Scan on *VALUES* (cost=0.00..0.01 rows=1 width=4) (actual time=0.016..0.027 rows=1 loops=1) Output: *VALUES*.column1, *VALUES*.column2 - Values Scan on *VALUES* (cost=0.00..0.01 rows=1 width=4) (actual time=0.013..0.024 rows=1 loops=1) Output: *VALUES*.column1, *VALUES*.column2 Total runtime: 0.209 ms (8 rows) mboguk=# explain (analyze, verbose) SELECT a.val, b.val FROM (VALUES( (1), (2) )) AS a (val) JOIN (VALUES( (2), (42) )) AS b (val) ON a.val = b.val; QUERY PLAN - Nested Loop (cost=0.00..0.04 rows=1 width=8) (actual time=0.056..0.056 rows=0 loops=1) Output: *VALUES*.column1, *VALUES*.column1 Join Filter: (*VALUES*.column1 = *VALUES*.column1) Rows Removed by Join Filter: 1 - Values Scan on *VALUES* (cost=0.00..0.01 rows=1 width=4) (actual time=0.008..0.013 rows=1 loops=1) Output: *VALUES*.column1, *VALUES*.column2 - Values Scan on *VALUES* (cost=0.00..0.01 rows=1 width=4) (actual time=0.007..0.013 rows=1 loops=1) Output: *VALUES*.column1, *VALUES*.column2 Total runtime: 0.100 ms (9 rows) -- 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 #7612: Wrong result with join between two values () set
On 10/19/12, Vik Reykja vikrey...@gmail.com wrote: On Thu, Oct 18, 2012 at 5:40 PM, maxim.bo...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 7612 Logged by: Maxim Boguk Email address: maxim.bo...@gmail.com PostgreSQL version: 9.2.1 Operating system: Linux Description: Join between two values() set could produce wrong results: This is not a bug; your test case produces correct results. Your VALUES clauses are producing one row with two columns each called val and column2. You are joining on val and so when you switch the values to put 2 in different columns, no results are found. Is it possible you didn't intend to put the parentheses immediately following the VALUES keyword? I think that is the case because your parentheses around the numbers are superfluous. Oops sorry for noise. I should be more careful. -- 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 Tue, Oct 16, 2012 at 9:31 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 15.10.2012 19:31, Fujii Masao wrote: On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 15.10.2012 13:13, Heikki Linnakangas wrote: 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. Yeah, clearly I didn't test this near enough... I fixed the bugs you bumped into, new version attached. Thanks for updating the patch! We should remove the check of integer_datetime by pg_basebackup background process and pg_receivexlog? Currently, they always check it, and then if its setting value is not the same between a client and server, they fail. Thanks to the patch, ISTM this check is no longer required. + pq_sendint64(reply_message, GetCurrentIntegerTimestamp()); In XLogWalRcvSendReply() and XLogWalRcvSendHSFeedback(), GetCurrentTimestamp() is called twice. I think that we can skip the latter call if integer-datetime is enabled because the return value of GetCurrentTimestamp() and GetCurrentIntegerTimestamp() is in the same format. It's worth reducing the number of GetCurrentTimestamp() calls, I think. elog(DEBUG2, sending write %X/%X flush %X/%X apply %X/%X, -(uint32) (reply_message.write 32), (uint32) reply_message.write, -(uint32) (reply_message.flush 32), (uint32) reply_message.flush, -(uint32) (reply_message.apply 32), (uint32) reply_message.apply); +(uint32) (writePtr 32), (uint32) writePtr, +(uint32) (flushPtr 32), (uint32) flushPtr, +(uint32) (applyPtr 32), (uint32) applyPtr); elog(DEBUG2, write %X/%X flush %X/%X apply %X/%X, -(uint32) (reply.write 32), (uint32) reply.write, -(uint32) (reply.flush 32), (uint32) reply.flush, -(uint32) (reply.apply 32), (uint32) reply.apply); +(uint32) (writePtr 32), (uint32) writePtr, +(uint32) (flushPtr 32), (uint32) flushPtr, +(uint32) (applyPtr 32), (uint32) applyPtr); Isn't it worth logging not only WAL location but also the replyRequested flag in these debug message? The remaining of the patch looks good to me. + hdrlen = sizeof(int64) + sizeof(int64) + sizeof(int64); + hdrlen = sizeof(int64) + sizeof(int64) + sizeof(char); These should be macro, to avoid calculation overhead? The compiler will calculate this at compilation time, it's going to be a constant at runtime. Yes, you're right. 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
[BUGS] BUG #7611: \copy (and COPY?) incorrectly parses nul character for windows-1252
The following bug has been logged on the website: Bug reference: 7611 Logged by: James Email address: sams.james+postg...@gmail.com PostgreSQL version: 9.1.6 Operating system: Ubuntu Linux 12.04 Description: I have a file with several nul characters in it. The file itself appears to be encoded as windows-1252, though I am not 100% certain of that. I do know that other software (e.g. Python) can decode the data as windows-1252 without issue. Postgres's \copy, however, chokes on the nul byte: ERROR: unterminated CSV quoted field CONTEXT: COPY promo_nonactive_load_fake, line 239900 Note that the error is wrong, the field is quoted but postgres seems to jump forward in the file when it encounters the nul bytes. Further, the line number is wrong. That is the length of the file (in lines), not the line on which the error occurs, which is several hundred lines before this. Deleting the nul byte characters allowed copy to proceed normally. I experienced similar issues with psycopg2 and copy_expert using COPY FROM STDIN and this file. -- 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 #7611: \copy (and COPY?) incorrectly parses nul character for windows-1252
sams.james+postg...@gmail.com writes: I have a file with several nul characters in it. The file itself appears to be encoded as windows-1252, though I am not 100% certain of that. I do know that other software (e.g. Python) can decode the data as windows-1252 without issue. Postgres's \copy, however, chokes on the nul byte: ERROR: unterminated CSV quoted field CONTEXT: COPY promo_nonactive_load_fake, line 239900 Postgres doesn't support nul characters in data, so the best you could hope for here is an error message anyway. It looks to me like the immediate cause of this is that \copy reads the file with fgets() which will effectively ignore the rest of the line after a nul byte. But there are probably more issues downstream. 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] Fwd: race in pg_ctl start -w
On 10/15/2012 4:06 AM, Heikki Linnakangas wrote: On 11.10.2012 22:36, Tom Lane wrote: Heikki Linnakangashlinnakan...@vmware.com 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 Heikki, It's happy about the overruns. It did flag an issue where the file descriptor can leak when the various early returns get taken. - Dave -- 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
Dave Vitek wrote: Heikki, It's happy about the overruns. It did flag an issue where the file descriptor can leak when the various early returns get taken. This is a common problem with static analysers; they don't realise we don't care about the leaked resource because the program is shortly going to terminate anyway. We (used to?) have plenty of false positives in initdb as reported in the Coverity scanner, for example. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- 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 #7521: Cannot disable WAL log while using pg_dump
You may disable full_page_writes, but as you can see from my previous post, disabling it did not do the trick. My zfs' USED property continues to increase. On Wed, Oct 17, 2012 at 3:55 PM, ichbinrene rene.romer...@gmail.com wrote: I'm experiencing the exact same issue: PostgreSQL 9.1.6 on i686-pc-linux-gnu, compiled by gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4), 32-bit CentOS release 6.3 (Final) I might also turn full_page_writes off but I fear for data integrity in case of a crash . -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-7521-Cannot-disable-WAL-log-while-using-pg-dump-tp5722846p5728727.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 -- 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 18.10.2012 22:15, Alvaro Herrera wrote: Dave Vitek wrote: Heikki, It's happy about the overruns. It did flag an issue where the file descriptor can leak when the various early returns get taken. This is a common problem with static analysers; they don't realise we don't care about the leaked resource because the program is shortly going to terminate anyway. We (used to?) have plenty of false positives in initdb as reported in the Coverity scanner, for example. Actually, this was a real leak. I should've put close() calls to the cases where the file is empty, or fstat() fails. It doesn't matter when the function is called only once, but in the pg_ctl start -w case it's called repeatedly to poll for postmaster startup. Fixed, and I also changed it to not return the last line if it doesn't end in a newline, per Tom's suggestion. - Heikki -- 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 #7613: INTIDB
The following bug has been logged on the website: Bug reference: 7613 Logged by: Henrique Silva Email address: henrique.assesso...@hotmail.com PostgreSQL version: 8.3.20 Operating system: Windows Seven Description: Falha ao executar o Initdb.1! -- 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 #7613: INTIDB
On 10/19/2012 03:13 AM, henrique.assesso...@hotmail.com wrote: The following bug has been logged on the website: Bug reference: 7613 Logged by: Henrique Silva Email address: henrique.assesso...@hotmail.com PostgreSQL version: 8.3.20 Operating system: Windows Seven Description: Falha ao executar o Initdb.1! There's no sign this is a bug. It looks more likely that the permissions on initdb are wrong. Please read: wiki.postgresql.org/wiki/Guide_to_reporting_problems and follow up with a question on pgsql-general or superuser.com if you continue to have problems. -- 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
