Re: 9.3 release notes suggestions - Mailing list 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:
> >
> >         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. +