Re: [REVIEW] pg_last_xact_insert_timestamp
| От | Fujii Masao |
|---|---|
| Тема | Re: [REVIEW] pg_last_xact_insert_timestamp |
| Дата | |
| Msg-id | CAHGQGwG0C21F0CZY5ExX-49dxdx7hJuNeiBBJ0Tzvh+7vMXWgw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [REVIEW] pg_last_xact_insert_timestamp (Kyotaro HORIGUCHI <horiguchi.kyotaro@oss.ntt.co.jp>) |
| Ответы |
Re: [REVIEW] pg_last_xact_insert_timestamp
|
| Список | pgsql-hackers |
On Thu, Sep 29, 2011 at 5:20 PM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@oss.ntt.co.jp> wrote:
> Sorry for late to re-review.
Thanks!
>> > Nevertheless this is ok for all OSs, I don't know whether
>> > initializing TimestampTz(double, int64 is ok) field with 8 bytes
>> > zeros is OK or not, for all platforms. (It is ok for
>> > IEEE754-binary64).
>>
>> Which code are you concerned about?
>
> xlog.c: 5889
>> beentry = pgstat_fetch_all_beentry();
>>
>> for (i = 0; i < MaxBackends; i++, beentry++)
>> {
>> xtime = beentry->st_xact_end_timestamp;
>
> I think the last line in quoted code above reads possibly
> zero-initialized double (or int64) value, then the doubted will
> be compared and copied to another double.
>
>> if (result < xtime)
>> result = xtime;
I believe it's safe. Such a code is placed elsewhere in the source, too.
If it's unsafe, we should have received lots of bug reports related
to that. But we've not.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: