Re: [HACKERS] 9.3 release notes suggestions
On Mon, Aug 19, 2013 at 01:38:13PM +0900, Etsuro Fujita wrote: From: 'Bruce Momjian' [mailto:br...@momjian.us] On Tue, Aug 13, 2013 at 05:59:05PM +0900, Etsuro Fujita wrote: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. One small suggestion: listitem para Allow link linkend=SQL-CREATEFOREIGNDATAWRAPPERforeign data wrappers/link to support writes (inserts/updates/deletes) on foreign tables (KaiGai Kohei) /para /listitem This is the in-core functionality, so ISTM it would be better that this is stated in the section of Object Manipulation rather than in that of Additional Modules. Please find attached a patch. Agreed, done. Thanks! I have another small suggestion about the recent changes in 9.3 release notes. I think it would be better that a headline feature is listed without its author. Please find attached a patch. Thanks, applied and backpatched. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
From: 'Bruce Momjian' [mailto:br...@momjian.us] On Tue, Aug 13, 2013 at 05:59:05PM +0900, Etsuro Fujita wrote: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. One small suggestion: listitem para Allow link linkend=SQL-CREATEFOREIGNDATAWRAPPERforeign data wrappers/link to support writes (inserts/updates/deletes) on foreign tables (KaiGai Kohei) /para /listitem This is the in-core functionality, so ISTM it would be better that this is stated in the section of Object Manipulation rather than in that of Additional Modules. Please find attached a patch. Agreed, done. Thanks! I have another small suggestion about the recent changes in 9.3 release notes. I think it would be better that a headline feature is listed without its author. Please find attached a patch. Thanks, Best regards, Etsuro Fujita release-9.3.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. One small suggestion: listitem para Allow link linkend=SQL-CREATEFOREIGNDATAWRAPPERforeign data wrappers/link to support writes (inserts/updates/deletes) on foreign tables (KaiGai Kohei) /para /listitem This is the in-core functionality, so ISTM it would be better that this is stated in the section of Object Manipulation rather than in that of Additional Modules. Please find attached a patch. Thanks, Best regards, Etsuro Fujita REL9_3_BETA2_release.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On Tue, Aug 13, 2013 at 05:59:05PM +0900, Etsuro Fujita wrote: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. One small suggestion: listitem para Allow link linkend=SQL-CREATEFOREIGNDATAWRAPPERforeign data wrappers/link to support writes (inserts/updates/deletes) on foreign tables (KaiGai Kohei) /para /listitem This is the in-core functionality, so ISTM it would be better that this is stated in the section of Object Manipulation rather than in that of Additional Modules. Please find attached a patch. Agreed, done. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On May 5, 2013, at 11:51 AM, Andrew Dunstan and...@dunslane.net wrote: I can't off the top of my head see any good reason for zero padding, so I'm with Tom. Same here. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On Mon, May 6, 2013 at 06:54:06AM -0400, Robert Haas wrote: On May 5, 2013, at 11:51 AM, Andrew Dunstan and...@dunslane.net wrote: I can't off the top of my head see any good reason for zero padding, so I'm with Tom. Same here. Agreed, reverted. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On 05.05.2013 18:51, Andrew Dunstan wrote: On 05/05/2013 01:35 AM, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: OK, so we can either use 4 hex digits minimum and have a fixed with on most platforms, extend it to 8 hex digits, or revert the entire fixed-width idea. I think we should lose the idea that it's fixed-width. 16-bit PIDs are a limitation whose days are obviously numbered. I'm late to this party - I must have been asleep at the wheel back in October, but I guess I have an interest as the original author of log_line_prefix ;-) I can't off the top of my head see any good reason for zero padding, so I'm with Tom. Agreed. What might be useful, is a general padding feature in log_line_prefix, like in sprintf: log_line_prefix = '%.5p ' - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On Mon, May 6, 2013 at 06:23:07PM +0300, Heikki Linnakangas wrote: On 05.05.2013 18:51, Andrew Dunstan wrote: On 05/05/2013 01:35 AM, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: OK, so we can either use 4 hex digits minimum and have a fixed with on most platforms, extend it to 8 hex digits, or revert the entire fixed-width idea. I think we should lose the idea that it's fixed-width. 16-bit PIDs are a limitation whose days are obviously numbered. I'm late to this party - I must have been asleep at the wheel back in October, but I guess I have an interest as the original author of log_line_prefix ;-) I can't off the top of my head see any good reason for zero padding, so I'm with Tom. Agreed. What might be useful, is a general padding feature in log_line_prefix, like in sprintf: log_line_prefix = '%.5p ' Yes, I can see that as useful, especially for things like username and database name. TODO item? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On 05/05/13 17:35, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: OK, so we can either use 4 hex digits minimum and have a fixed with on most platforms, extend it to 8 hex digits, or revert the entire fixed-width idea. I think we should lose the idea that it's fixed-width. 16-bit PIDs are a limitation whose days are obviously numbered. regards, tom lane I think fixed width _*is*_ useful, it looks neater and is easier to parse. However, it would mean at least 4 leading zeros for systems with only 16 bit PID's. Cheers, Gavin
Re: [HACKERS] 9.3 release notes suggestions
On 05/05/2013 01:35 AM, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: OK, so we can either use 4 hex digits minimum and have a fixed with on most platforms, extend it to 8 hex digits, or revert the entire fixed-width idea. I think we should lose the idea that it's fixed-width. 16-bit PIDs are a limitation whose days are obviously numbered. I'm late to this party - I must have been asleep at the wheel back in October, but I guess I have an interest as the original author of log_line_prefix ;-) I can't off the top of my head see any good reason for zero padding, so I'm with Tom. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
2013/4/24 Bruce Momjian br...@momjian.us: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. One small suggestion: listitem para Have quotesession id/ (literal%c/) in link linkend=guc-log-line-prefixvarnamelog_line_prefix//link always output four hex digits after the period (Bruce Momjian) /para /listitem This doesn't sound quite right - on OS X at least, PIDs go up to 8, which means %c may output 5 hex digits after the period. The following might be more pedantically accurate: listitem para Have quotesession id/ (literal%c/) in link linkend=guc-log-line-prefixvarnamelog_line_prefix//link always pad the PID value with zeros so at least four hex digits are displayed after the period (Bruce Momjian) /para /listitem if my slightly disengaged brain is grokking the source correctly: src/backend/utils/error/elog.c: appendStringInfo(buf, %lx.%04x, (long) (MyStartTime), MyProcPid); Regards Ian Barwick -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
Hi! On Wed, Apr 24, 2013 at 6:41 AM, Bruce Momjian br...@momjian.us wrote: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. Some observations: 1. Allow CREATE TABLE IF NOT EXISTS to succeed for a non-existent schema This should be DROP TABLE IF EXISTS. Clearly CREATE cannot succeed without a schema :) 2. Dramatically reduce System V shared memory usage I find this description misleading. When reading for the first time, it sounds as if Postgres memory usage is reduced, but it's actually just using different kind of shared memory. How about Use mmap() instead of System V shared memory on Unix systems Regards, Marti -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On Sat, May 4, 2013 at 08:34:18PM +0900, Ian Lawrence Barwick wrote: 2013/4/24 Bruce Momjian br...@momjian.us: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. One small suggestion: listitem para Have quotesession id/ (literal%c/) in link linkend=guc-log-line-prefixvarnamelog_line_prefix//link always output four hex digits after the period (Bruce Momjian) /para /listitem This doesn't sound quite right - on OS X at least, PIDs go up to 8, which means %c may output 5 hex digits after the period. The following might be Oh, I was curious if some OS had larger pid values. I am concerned you aren't going to get session ids of consistent length on that platform. more pedantically accurate: listitem para Have quotesession id/ (literal%c/) in link linkend=guc-log-line-prefixvarnamelog_line_prefix//link always pad the PID value with zeros so at least four hex digits are displayed after the period (Bruce Momjian) /para /listitem OK, changed to: Have quotesession id/ (literal%c/) in link linkend=guc-log-line-prefixvarnamelog_line_prefix//link always output at least four hex digits after the period (Bruce Momjian) This is such a minor change I am trying to keep it short. if my slightly disengaged brain is grokking the source correctly: src/backend/utils/error/elog.c: appendStringInfo(buf, %lx.%04x, (long) (MyStartTime), MyProcPid); Yep. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On Sat, May 4, 2013 at 03:50:34PM +0300, Marti Raudsepp wrote: Hi! On Wed, Apr 24, 2013 at 6:41 AM, Bruce Momjian br...@momjian.us wrote: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. Some observations: 1. Allow CREATE TABLE IF NOT EXISTS to succeed for a non-existent schema This should be DROP TABLE IF EXISTS. Clearly CREATE cannot succeed without a schema :) Seems I can only blame my own commit message for that confusion. :-( Fixed. 2. Dramatically reduce System V shared memory usage I find this description misleading. When reading for the first time, it sounds as if Postgres memory usage is reduced, but it's actually just using different kind of shared memory. How about Use mmap() instead of System V shared memory on Unix systems I changed it to: Dramatically reduce System V link linkend=sysvipcshared memory/link requirements (Robert Haas) -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On Sat, May 4, 2013 at 03:50:34PM +0300, Marti Raudsepp wrote: 2. Dramatically reduce System V shared memory usage I find this description misleading. When reading for the first time, it sounds as if Postgres memory usage is reduced, but it's actually just using different kind of shared memory. How about Use mmap() instead of System V shared memory on Unix systems Repost: I changed usage to required, which I think is more accurate. The detail below the item explains it is for Unix-like systems, and uses mmap(), which I think is the proper place for those details. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
2013/5/4 Bruce Momjian br...@momjian.us: On Sat, May 4, 2013 at 08:34:18PM +0900, Ian Lawrence Barwick wrote: 2013/4/24 Bruce Momjian br...@momjian.us: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. One small suggestion: listitem para Have quotesession id/ (literal%c/) in link linkend=guc-log-line-prefixvarnamelog_line_prefix//link always output four hex digits after the period (Bruce Momjian) /para /listitem This doesn't sound quite right - on OS X at least, PIDs go up to 8, which means %c may output 5 hex digits after the period. The following might be Oh, I was curious if some OS had larger pid values. I am concerned you aren't going to get session ids of consistent length on that platform. more pedantically accurate: listitem para Have quotesession id/ (literal%c/) in link linkend=guc-log-line-prefixvarnamelog_line_prefix//link always pad the PID value with zeros so at least four hex digits are displayed after the period (Bruce Momjian) /para /listitem OK, changed to: Have quotesession id/ (literal%c/) in link linkend=guc-log-line-prefixvarnamelog_line_prefix//link always output at least four hex digits after the period (Bruce Momjian) This is such a minor change I am trying to keep it short. Just out of curiosity, what was the reason for the change in the first place? (Not that it's something I'm particularly passionate about, I just noticed it when listing changes with potential backwards-compatibilty effects for the wiki). if my slightly disengaged brain is grokking the source correctly: src/backend/utils/error/elog.c: appendStringInfo(buf, %lx.%04x, (long) (MyStartTime), MyProcPid); Yep. In that case maybe the docs need updating as well? http://www.postgresql.org/docs/devel/static/runtime-config-logging.html#GUC-LOG-LINE-PREFIX The %c escape prints a quasi-unique session identifier, consisting of two 4-byte hexadecimal numbers (without leading zeros) separated by a dot. Regards Ian Barwick -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On Sat, May 4, 2013 at 11:55:09PM +0900, Ian Lawrence Barwick wrote: more pedantically accurate: listitem para Have quotesession id/ (literal%c/) in link linkend=guc-log-line-prefixvarnamelog_line_prefix//link always pad the PID value with zeros so at least four hex digits are displayed after the period (Bruce Momjian) /para /listitem OK, changed to: Have quotesession id/ (literal%c/) in link linkend=guc-log-line-prefixvarnamelog_line_prefix//link always output at least four hex digits after the period (Bruce Momjian) This is such a minor change I am trying to keep it short. Just out of curiosity, what was the reason for the change in the first place? (Not that it's something I'm particularly passionate about, I just noticed it when listing changes with potential backwards-compatibilty effects for the wiki). Well, basically, if you used %c in log_line_prefix, the session id was not a fixed length, so your output shifted around based on the pid, see: http://www.postgresql.org/message-id/20121012185127.gb31...@momjian.us Always showing four digits seems to give greater consistency to the log output. if my slightly disengaged brain is grokking the source correctly: src/backend/utils/error/elog.c: appendStringInfo(buf, %lx.%04x, (long) (MyStartTime), MyProcPid); Yep. In that case maybe the docs need updating as well? http://www.postgresql.org/docs/devel/static/runtime-config-logging.html#GUC-LOG-LINE-PREFIX The %c escape prints a quasi-unique session identifier, consisting of two 4-byte hexadecimal numbers (without leading zeros) separated by a dot. Uh, that was never right, because the part before the dot is the session start timestamp, and that is 8 hex digits: 50785b3e.7ff9 I have changed the text to: The literal%c/ escape prints a quasi-unique session identifier, consisting of two hexadecimal numbers separated by a dot. Doc fix backpatched to 9.2.X. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions (typo)
Plural to singular: s/Allow a streaming replication standbys to/Allow a streaming replication standby to/ Perhaps this one too? (not sure, 'tooling' just seems strange to my non-native reading)) s/Allow tooling like pg_receivexlog to run/Allow tools like pg_receivexlog to run/ thanks, Erik Rijkers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions (typo)
On Sat, May 4, 2013 at 05:12:31PM +0200, Erik Rijkers wrote: Plural to singular: s/Allow a streaming replication standbys to/Allow a streaming replication standby to/ Perhaps this one too? (not sure, 'tooling' just seems strange to my non-native reading)) s/Allow tooling like pg_receivexlog to run/Allow tools like pg_receivexlog to run/ Agreed. Doc fix applied and attached. Thanks. Your documentation changes can be viewed in five minutes at: http://momjian.postgresql.org/pgsql_docs/ -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml new file mode 100644 index 94db2f7..32839b7 *** a/doc/src/sgml/release-9.3.sgml --- b/doc/src/sgml/release-9.3.sgml *** *** 518,524 listitem para ! Allow a streaming replication standbys to link linkend=protocol-replicationfollow a timeline switch/link (Heikki Linnakangas) /para --- 518,524 listitem para ! Allow a streaming replication standby to link linkend=protocol-replicationfollow a timeline switch/link (Heikki Linnakangas) /para *** *** 574,580 listitem para ! Allow tooling like link linkend=app-pgreceivexlogapplicationpg_receivexlog//link to run on computers with different architectures (Heikki Linnakangas) --- 574,580 listitem para ! Allow tools like link linkend=app-pgreceivexlogapplicationpg_receivexlog//link to run on computers with different architectures (Heikki Linnakangas) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
2013/5/5 Bruce Momjian br...@momjian.us: (...) This is such a minor change I am trying to keep it short. Just out of curiosity, what was the reason for the change in the first place? (Not that it's something I'm particularly passionate about, I just noticed it when listing changes with potential backwards-compatibilty effects for the wiki). Well, basically, if you used %c in log_line_prefix, the session id was not a fixed length, so your output shifted around based on the pid, see: http://www.postgresql.org/message-id/20121012185127.gb31...@momjian.us Always showing four digits seems to give greater consistency to the log output. Makes sense as long as your PIDs stay below 0x1, but on OS X it makes it less consistent IMHO, as you still end up with a varying number of digits: 5184ea1f.15ed2 LOG: database system was shut down at 2013-05-04 19:59:41 JST 5184ea1f.15ed1 LOG: database system is ready to accept connections 5184ea1f.15ed6 LOG: autovacuum launcher started 5184ea23.15edb ERROR: column x does not exist at character 8 5184ea23.15edb STATEMENT: select x; 51852890.0a0a ERROR: column x does not exist at character 8 51852890.0a0a STATEMENT: select x; (tested using 9.3 HEAD) if my slightly disengaged brain is grokking the source correctly: src/backend/utils/error/elog.c: appendStringInfo(buf, %lx.%04x, (long) (MyStartTime), MyProcPid); Yep. In that case maybe the docs need updating as well? http://www.postgresql.org/docs/devel/static/runtime-config-logging.html#GUC-LOG-LINE-PREFIX The %c escape prints a quasi-unique session identifier, consisting of two 4-byte hexadecimal numbers (without leading zeros) separated by a dot. Uh, that was never right, because the part before the dot is the session start timestamp, and that is 8 hex digits: 50785b3e.7ff9 I understood it as a 4-byte number expressed in hex, which in this case even without zero padding is always going to be 8 hex digits unless your system clock is stuck in the 1970s. I have changed the text to: The literal%c/ escape prints a quasi-unique session identifier, consisting of two hexadecimal numbers separated by a dot. Doc fix backpatched to 9.2.X. Covers all bases :) However it just occurred to me the example following that paragraph is incorrect for 9.3, as the to_hex(pid) output won't be zero-padded. Sorry to be pedantic about this, like I said it's not something I am particularly passionate about and I'd never even taken notice of the %c option, but at least on OS X the documentation didn't match the observed behaviour. Regards Ian Barwick -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On Sun, May 5, 2013 at 01:21:12AM +0900, Ian Lawrence Barwick wrote:
Well, basically, if you used %c in log_line_prefix, the session id was
not a fixed length, so your output shifted around based on the pid, see:
http://www.postgresql.org/message-id/20121012185127.gb31...@momjian.us
Always showing four digits seems to give greater consistency to the
log output.
Makes sense as long as your PIDs stay below 0x1, but on OS X it makes
it less consistent IMHO, as you still end up with a varying number of digits:
5184ea1f.15ed2 LOG: database system was shut down at 2013-05-04 19:59:41 JST
5184ea1f.15ed1 LOG: database system is ready to accept connections
5184ea1f.15ed6 LOG: autovacuum launcher started
5184ea23.15edb ERROR: column x does not exist at character 8
5184ea23.15edb STATEMENT: select x;
51852890.0a0a ERROR: column x does not exist at character 8
51852890.0a0a STATEMENT: select x;
(tested using 9.3 HEAD)
OK, that's a serious argument that we should just revert this entire
change to do padding of %c. If we can't do it consistently on all
patforms, it seems undesirable. What is the Windows max for getpid()?
http://www.postgresql.org/docs/devel/static/runtime-config-logging.html#GUC-LOG-LINE-PREFIX
The %c escape prints a quasi-unique session identifier, consisting of
two 4-byte hexadecimal numbers (without leading zeros) separated by a
dot.
Uh, that was never right, because the part before the dot is the session
start timestamp, and that is 8 hex digits:
50785b3e.7ff9
I understood it as a 4-byte number expressed in hex, which in this
case even without
zero padding is always going to be 8 hex digits unless your system
clock is stuck in the 1970s.
Yes, I got that confused in my head between 4-bytes and 4-digits. :-(
I have reverted the doc change and re-added the 4-byte specification.
I have changed the text to:
The literal%c/ escape prints a quasi-unique session
identifier,
consisting of two hexadecimal numbers separated by a dot.
Doc fix backpatched to 9.2.X.
Covers all bases :)
However it just occurred to me the example following that paragraph is
incorrect
for 9.3, as the to_hex(pid) output won't be zero-padded.
Yes, I see it is wrong now. I came up with this new query:
SELECT to_hex(EXTRACT(EPOCH FROM backend_start)::integer) || '.' ||
regexp_replace('' || to_hex(pid), '^0*(.*)$', '\1')
FROM pg_stat_activity;
It removes some leading zeros, but guarantees 4 digits.
I have updated to that new query to our docs too. Is there a better
regex for this?
Sorry to be pedantic about this, like I said it's not something I am
particularly
passionate about and I'd never even taken notice of the %c option, but at
least
on OS X the documentation didn't match the observed behaviour.
I would love to see the session id used more often, and this change was
part of that plan. However, I am starting to wonder.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On Sat, May 4, 2013 at 01:17:44PM -0400, Bruce Momjian wrote:
Yes, I see it is wrong now. I came up with this new query:
SELECT to_hex(EXTRACT(EPOCH FROM backend_start)::integer) || '.' ||
regexp_replace('' || to_hex(pid), '^0*(.*)$', '\1')
FROM pg_stat_activity;
It removes some leading zeros, but guarantees 4 digits.
I have updated to that new query to our docs too. Is there a better
regex for this?
OK, I thought of a better one:
SELECT to_hex(EXTRACT(EPOCH FROM backend_start)::integer) || '.' ||
regexp_replace('' || '0133e3', '^0*(.{4,})$', '\1')
FROM pg_stat_activity;
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On 24.4.2013 05:41, Bruce Momjian wrote: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. Lovely, good job Bruce! I've checked descriptions of changes I've been working on, and I think this one is incorrect: -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On 24.4.2013 05:41, Bruce Momjian wrote: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. Lovely, good job Bruce! I've checked descriptions of changes I've been working on, and I think this one is incorrect: Improve performance for transactions creating, rebuilding, or dropping many relations (Jeff Janes, Tomas Vondra) I assume this is commit 279628a0a7cf582f7dfb68e25b7b76183dd8ff2f. That however improves DROP only - it has nothing to do with creating or rebuilding relations. Or is it a condensed description of changes made by some other patches? Tomas PS: Sorry for the partial message a few minutes ago. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On Sat, May 4, 2013 at 07:59:40PM +0200, Tomas Vondra wrote: On 24.4.2013 05:41, Bruce Momjian wrote: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. Lovely, good job Bruce! I've checked descriptions of changes I've been working on, and I think this one is incorrect: Improve performance for transactions creating, rebuilding, or dropping many relations (Jeff Janes, Tomas Vondra) I assume this is commit 279628a0a7cf582f7dfb68e25b7b76183dd8ff2f. That however improves DROP only - it has nothing to do with creating or rebuilding relations. Or is it a condensed description of changes made by some other patches? Yes, it is a composite of your patch and one by Jeff Janes: Fix an O(N^2) performance issue for sessions modifying many relations. AtEOXact_RelationCache() scanned the entire relation cache at the end of any transaction that created a new relation or assigned a new relfilenode. Thus, clients such as pg_restore had an O(N^2) performance problem that would start to be noticeable after creating 1 or so tables. Since typically only a small number of relcache entries need any cleanup, we can fix this by keeping a small list of their OIDs and doing hash_searches for them. We fall back to the full-table scan if the list overflows. Ideally, the maximum list length would be set at the point where N hash_searches would cost just less than the full-table scan. Some quick experimentation says that point might be around 50-100; I (tgl) conservatively set MAX_EOXACT_LIST = 32. For the case that we're worried about here, which is short single-statement transactions, it's unlikely there would ever be more than about a dozen list entries anyway; so it's probably not worth being too tense about the value. We could avoid the hash_searches by instead keeping the target relcache entries linked into a list, but that would be noticeably more complicated and bug-prone because of the need to maintain such a list in the face of relcache entry drops. Since a relcache entry can only need such cleanup after a somewhat-heavyweight filesystem operation, trying to save a hash_search per cleanup doesn't seem very useful anyway --- it's the scan over all the not-needing-cleanup entries that we wish to avoid here. Jeff Janes, reviewed and tweaked a bit by Tom Lane (Tom Lane) [d5b31cc32] 2013-01-20 13:45:10 -0500 -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On Sat, May 04, 2013 at 01:17:44PM -0400, Bruce Momjian wrote: On Sun, May 5, 2013 at 01:21:12AM +0900, Ian Lawrence Barwick wrote: Well, basically, if you used %c in log_line_prefix, the session id was not a fixed length, so your output shifted around based on the pid, see: http://www.postgresql.org/message-id/20121012185127.gb31...@momjian.us Always showing four digits seems to give greater consistency to the log output. Makes sense as long as your PIDs stay below 0x1, but on OS X it makes it less consistent IMHO, as you still end up with a varying number of digits: 5184ea1f.15ed2 LOG: database system was shut down at 2013-05-04 19:59:41 JST 5184ea1f.15ed1 LOG: database system is ready to accept connections 5184ea1f.15ed6 LOG: autovacuum launcher started 5184ea23.15edb ERROR: column x does not exist at character 8 5184ea23.15edb STATEMENT: select x; 51852890.0a0a ERROR: column x does not exist at character 8 51852890.0a0a STATEMENT: select x; (tested using 9.3 HEAD) OK, that's a serious argument that we should just revert this entire change to do padding of %c. If we can't do it consistently on all patforms, it seems undesirable. What is the Windows max for getpid()? Not sure about Windows, but the limit on systems using the Linux kernel is based on the kernel.pid_max sysctl. That setting defaults to 32768, but I can set it as high as 4194304 (2^22) on the system most handy. When I last used 32-bit IRIX 6.5, its PIDs seemed to never wrap; a web search suggests it had a limit of 2^31. POSIX permits any signed integral type for pid_t. To make %c fixed-width, we could check pid_t at build time or unconditionally allow for 63-bit PIDs. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On Sat, May 4, 2013 at 10:01:18PM -0400, Noah Misch wrote: On Sat, May 04, 2013 at 01:17:44PM -0400, Bruce Momjian wrote: On Sun, May 5, 2013 at 01:21:12AM +0900, Ian Lawrence Barwick wrote: Well, basically, if you used %c in log_line_prefix, the session id was not a fixed length, so your output shifted around based on the pid, see: http://www.postgresql.org/message-id/20121012185127.gb31...@momjian.us Always showing four digits seems to give greater consistency to the log output. Makes sense as long as your PIDs stay below 0x1, but on OS X it makes it less consistent IMHO, as you still end up with a varying number of digits: 5184ea1f.15ed2 LOG: database system was shut down at 2013-05-04 19:59:41 JST 5184ea1f.15ed1 LOG: database system is ready to accept connections 5184ea1f.15ed6 LOG: autovacuum launcher started 5184ea23.15edb ERROR: column x does not exist at character 8 5184ea23.15edb STATEMENT: select x; 51852890.0a0a ERROR: column x does not exist at character 8 51852890.0a0a STATEMENT: select x; (tested using 9.3 HEAD) OK, that's a serious argument that we should just revert this entire change to do padding of %c. If we can't do it consistently on all patforms, it seems undesirable. What is the Windows max for getpid()? Not sure about Windows, but the limit on systems using the Linux kernel is based on the kernel.pid_max sysctl. That setting defaults to 32768, but I can set it as high as 4194304 (2^22) on the system most handy. When I last used 32-bit IRIX 6.5, its PIDs seemed to never wrap; a web search suggests it had a limit of 2^31. POSIX permits any signed integral type for pid_t. To make %c fixed-width, we could check pid_t at build time or unconditionally allow for 63-bit PIDs. OK, so we can either use 4 hex digits minimum and have a fixed with on most platforms, extend it to 8 hex digits, or revert the entire fixed-width idea. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
Bruce Momjian br...@momjian.us writes: OK, so we can either use 4 hex digits minimum and have a fixed with on most platforms, extend it to 8 hex digits, or revert the entire fixed-width idea. I think we should lose the idea that it's fixed-width. 16-bit PIDs are a limitation whose days are obviously numbered. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On Wed, Apr 24, 2013 at 6:30 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Apr 23, 2013 at 11:41 PM, Bruce Momjian br...@momjian.us wrote: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. Bruce, Thanks for writing them! Consider the sentiment duplicated. Thank you, Bruce. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On 04/25/2013 04:48 PM, Daniel Farina wrote: On Wed, Apr 24, 2013 at 6:30 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Apr 23, 2013 at 11:41 PM, Bruce Momjian br...@momjian.us wrote: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. Bruce, Thanks for writing them! Consider the sentiment duplicated. Thank you, Bruce. Isn't that a primary key violation? /me runs Sorry it has been a really long two days. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC @cmdpromptinc - 509-416-6579 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.3 release notes suggestions
On Tue, Apr 23, 2013 at 11:41 PM, Bruce Momjian br...@momjian.us wrote: Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. Bruce, Thanks for writing them! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 9.3 release notes suggestions
Thanks for the many suggestions on improving the 9.3 release notes. There were many ideas I would have never thought of. Please keep the suggestions coming. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
