9.3 release notes suggestions

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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
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>

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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:

/messages/by-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 numbers separated 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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

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. +

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:

/messages/by-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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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:

/messages/by-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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

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

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 10000 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 <bruce@momjian.us> http://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

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:

/messages/by-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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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:

/messages/by-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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 05/05/13 17:35, 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.

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers