Thread: 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Tue, Apr 23, 2013 at 11:41 PM, Bruce Momjian <bruce@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
On Wed, Apr 24, 2013 at 6:30 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Apr 23, 2013 at 11:41 PM, Bruce Momjian <bruce@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.
On 04/25/2013 04:48 PM, Daniel Farina wrote: > > On Wed, Apr 24, 2013 at 6:30 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Tue, Apr 23, 2013 at 11:41 PM, Bruce Momjian <bruce@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
2013/4/24 Bruce Momjian <bruce@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 <quote>session id</> (<literal>%c</>) in <link
linkend="guc-log-line-prefix"><varname>log_line_prefix</></link> always output four hex digits after the period
(BruceMomjian) </para> </listitem>
This doesn't sound quite right - on OS X at least, PIDs go up to
99998, which means
%c may output 5 hex digits after the period. The following might be
more pedantically
accurate:
<listitem> <para> Have <quote>session id</> (<literal>%c</>) in <link
linkend="guc-log-line-prefix"><varname>log_line_prefix</></link> always pad the PID value with zeros so at least
fourhex 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
Hi! On Wed, Apr 24, 2013 at 6:41 AM, Bruce Momjian <bruce@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
On Sat, May 4, 2013 at 08:34:18PM +0900, Ian Lawrence Barwick wrote:
> 2013/4/24 Bruce Momjian <bruce@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 <quote>session id</> (<literal>%c</>) in <link
> linkend="guc-log-line-prefix"><varname>log_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
> 99998, 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 <quote>session id</> (<literal>%c</>) in <link
> linkend="guc-log-line-prefix"><varname>log_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 <quote>session id</> (<literal>%c</>) in <link
linkend="guc-log-line-prefix"><varname>log_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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
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 <bruce@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="sysvipc">shared memory</link> requirements (Robert Haas)
------------
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
2013/5/4 Bruce Momjian <bruce@momjian.us>: > On Sat, May 4, 2013 at 08:34:18PM +0900, Ian Lawrence Barwick wrote: >> 2013/4/24 Bruce Momjian <bruce@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 <quote>session id</> (<literal>%c</>) in <link >> linkend="guc-log-line-prefix"><varname>log_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 >> 99998, 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 <quote>session id</> (<literal>%c</>) in <link >> linkend="guc-log-line-prefix"><varname>log_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 <quote>session id</> (<literal>%c</>) in <link > linkend="guc-log-line-prefix"><varname>log_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
On Sat, May 4, 2013 at 11:55:09PM +0900, Ian Lawrence Barwick wrote: > >> more pedantically > >> accurate: > >> > >> <listitem> > >> <para> > >> Have <quote>session id</> (<literal>%c</>) in <link > >> linkend="guc-log-line-prefix"><varname>log_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 <quote>session id</> (<literal>%c</>) in <link > > linkend="guc-log-line-prefix"><varname>log_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.GB31038@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 numbersseparated by a dot. Doc fix backpatched to 9.2.X. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
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
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 <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachment
2013/5/5 Bruce Momjian <bruce@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.GB31038@momjian.us > > Always showing four digits seems to give greater consistency to the > log output. Makes sense as long as your PIDs stay below 0x10000, 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
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.GB31038@momjian.us > > > > Always showing four digits seems to give greater consistency to the > > log output. > > Makes sense as long as your PIDs stay below 0x10000, 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('0000' || 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
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('0000' || 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('0000' || '0133e3',
'^0*(.{4,})$','\1')FROM pg_stat_activity;
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
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:
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.
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
entirerelation 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
10000or so tables. Since typically only a small number of relcache entries need any cleanup, we can fix this by
keepinga 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
thanthe full-table scan. Some quick experimentation says that point might be around 50-100; I (tgl)
conservativelyset 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
worthbeing too tense about the value. We could avoid the hash_searches by instead keeping the target relcache
entrieslinked into a list, but that would be noticeably more complicated and bug-prone because of the need to
maintainsuch a list in the face of relcache entry drops. Since a relcache entry can only need such cleanup after
asomewhat-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
tweakeda bit by Tom Lane(Tom Lane)[d5b31cc32] 2013-01-20 13:45:10 -0500
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
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.GB31038@momjian.us > > > > > > Always showing four digits seems to give greater consistency to the > > > log output. > > > > Makes sense as long as your PIDs stay below 0x10000, 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
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.GB31038@momjian.us > > > > > > > > Always showing four digits seems to give greater consistency to the > > > > log output. > > > > > > Makes sense as long as your PIDs stay below 0x10000, 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@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
<div class="moz-cite-prefix">On 05/05/13 17:35, Tom Lane wrote:<br /></div><blockquote
cite="mid:22174.1367732125@sss.pgh.pa.us"type="cite"><pre wrap="">Bruce Momjian <a class="moz-txt-link-rfc2396E"
href="mailto:bruce@momjian.us"><bruce@momjian.us></a>writes:
</pre><blockquote type="cite"><pre wrap="">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.
</pre></blockquote><pre wrap="">
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
</pre></blockquote><font size="-1">I think fi<font size="-1">x</font>ed width <u><b>is</b></u> useful, it looks neater
andis easier t<font size="-1">o parse</font>.<br /><br /><font size="-1">However, it would mean at least 4 leading
zerosfor systems with only 16 bit PID's.<br /><br /><br /><font size="-1">Cheers,<br /><font size="-1">Gavin</font><br
/></font></font></font>
On 05/05/2013 01:35 AM, Tom Lane wrote: > Bruce Momjian <bruce@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
On May 5, 2013, at 11:51 AM, Andrew Dunstan <andrew@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
On Mon, May 6, 2013 at 06:54:06AM -0400, Robert Haas wrote: > On May 5, 2013, at 11:51 AM, Andrew Dunstan <andrew@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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 05.05.2013 18:51, Andrew Dunstan wrote: > > On 05/05/2013 01:35 AM, Tom Lane wrote: >> Bruce Momjian <bruce@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
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 <bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
> 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-CREATEFOREIGNDATAWRAPPER">foreign data wrappers</link>
tosupport 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
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-CREATEFOREIGNDATAWRAPPER">foreign 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
> From: 'Bruce Momjian' [mailto:bruce@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-CREATEFOREIGNDATAWRAPPER">foreign 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
On Mon, Aug 19, 2013 at 01:38:13PM +0900, Etsuro Fujita wrote: > > From: 'Bruce Momjian' [mailto:bruce@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-CREATEFOREIGNDATAWRAPPER">foreign 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +