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
