Re: 9.3 release notes suggestions

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +