<div class="moz-cite-prefix">On 30/12/12 05:24, Tom Lane wrote:<br /></div><blockquote
cite="mid:11020.1356798245@sss.pgh.pa.us"type="cite"><pre wrap="">Andres Freund <a class="moz-txt-link-rfc2396E"
href="mailto:andres@2ndquadrant.com"><andres@2ndquadrant.com></a>writes:
</pre><blockquote type="cite"><pre wrap="">On 2012-12-29 07:23:24 -0500, Peter Eisentraut wrote:
</pre><blockquote type="cite"><pre wrap="">The xlog code uses two different time zone formats at various times.
</pre></blockquote></blockquote><pre wrap="">
</pre><blockquote type="cite"><pre wrap="">One is a pg_time_t (stored in pg_control/ControlFileData), the other is
a TimestampTz. Those have completely different code paths for being
printed (pg_strftime vs EncodeDateTime) ...
I don't want to say its impossible or shouldn't be fixed, just that its
not trivial to do so.
</pre></blockquote><pre wrap="">
Presumably, any fix would involve changing one or the other of those
so that we use only one timestamp representation in xlog. I'm not
terribly convinced that it's worth worrying about though. Do we need
microsecond precision in the database start/stop times?
regards, tom lane
</pre></blockquote><font size="-1">If I saw an <font size="-1">inconsistency</font> like that in </font>a production
log,while chasing an apparent case of corruption, I would tend to think that the differences in time might be giving me
ahint. Knowing my luck, that will happen to me in a couple of years, after I've forgotten this email tread!<br /><br
/><br/> Cheers,<br /> Gavin<br />