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