inconsistent time zone formats in log

Lists: pgsql-hackers
From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: inconsistent time zone formats in log
Date: 2012-12-29 12:23:24
Message-ID: 1356783804.20017.12.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

The xlog code uses two different time zone formats at various times.
Here is an example:

2012-12-29 07:04:07.338 EST LOG: database system was interrupted; last known up at 2012-12-29 06:27:02 EST
2012-12-29 07:04:26.347 EST LOG: last completed transaction was at log time 2012-12-29 06:34:24.394802-05

The second format also does not respect log_timezone, which seems a bit
of a bug.

It's also not clear why we need three different ways to show
milliseconds within the space of two lines.

Could we make some of this more consistent?


From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: inconsistent time zone formats in log
Date: 2012-12-29 12:43:11
Message-ID: 20121229124311.GA29478@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2012-12-29 07:23:24 -0500, Peter Eisentraut wrote:
> The xlog code uses two different time zone formats at various times.
> Here is an example:
>
> 2012-12-29 07:04:07.338 EST LOG: database system was interrupted; last known up at 2012-12-29 06:27:02 EST
> 2012-12-29 07:04:26.347 EST LOG: last completed transaction was at log time 2012-12-29 06:34:24.394802-05
>
> The second format also does not respect log_timezone, which seems a bit
> of a bug.
>
> It's also not clear why we need three different ways to show
> milliseconds within the space of two lines.

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.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: inconsistent time zone formats in log
Date: 2012-12-29 16:24:05
Message-ID: 11020.1356798245@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2012-12-29 07:23:24 -0500, Peter Eisentraut wrote:
>> The xlog code uses two different time zone formats at various times.

> 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.

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


From: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: inconsistent time zone formats in log
Date: 2012-12-29 18:59:04
Message-ID: 50DF3D78.4020603@archidevsys.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 30/12/12 05:24, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
>> On 2012-12-29 07:23:24 -0500, Peter Eisentraut wrote:
>>> The xlog code uses two different time zone formats at various times.
>> 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.
> 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
>
>
If I saw an inconsistency like that in a production log, while chasing
an apparent case of corruption, I would tend to think that the
differences in time might be giving me a hint. Knowing my luck, that
will happen to me in a couple of years, after I've forgotten this email
tread!

Cheers,
Gavin