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()? > >> 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 <br...@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
