Re: [HACKERS] pgsql y2k bug?

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] pgsql y2k bug?
Дата
Msg-id 200001020142.UAA04730@candle.pha.pa.us
обсуждение исходный текст
Ответ на pgsql y2k bug?  (Ed Loehr <eloehr@austin.rr.com>)
Ответы Re: [HACKERS] pgsql y2k bug?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> With pg 6.5.2, I just noticed this timestamped vacuum output in
> my log file...
>
> 1000101.18:14:18.555  [6514] DEBUG:  --Relation
> ui_option_choice--
> 1000101.18:14:18.555  [6514] DEBUG:  Pages 1: Changed 0, Reapped
> 0, Empty 0, New 0; Tup 5: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0,
> MinLen 68, MaxLen 100; Re-using: Free/Avail. Space 0/0;
> EndEmpty/Avail. Pages 0/0. Elapsed 0/0 sec.
> 1000101.18:14:18.558  [6514] DEBUG:  Index ui_option_choice_pkey:
> Pages 2; Tuples 5. Elapsed 0/0 sec.
> 1000101.18:14:18.558  [6514] DEBUG:  Index
> ui_option_choice_id_key: Pages 2; Tuples 5. Elapsed 0/0 sec.
> 1000101.18:14:18.570  [6514] DEBUG:  --Relation
> ui_default_preference--
>
> Notice the Jan 1, 100 A.D. timestamp...

OK, I have gone through all the code, looking at the handling of
tm_year, and found two possible areas for problems.  One was in
DATEDEBUG code that is ifdef'ed out and unused, and the trace code you
reported.

I am attaching a diff to fix the problem.  We were reporting only a
2-digit year, and tm_year reports years since 1900, so it was reporting
100 for year 2000.  The field was %02d, but the number was three digits
so it printed all three.

If we do not make a new release for this, the fix will appear in 7.0.

--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
*** ./backend/utils/misc/trace.c.orig    Sat Jan  1 20:37:01 2000
--- ./backend/utils/misc/trace.c    Sat Jan  1 20:37:15 2000
***************
*** 227,234 ****
      time = localtime(&tm);

      sprintf(pid, "[%d]", MyProcPid);
!     sprintf(timestamp, "%02d%02d%02d.%02d:%02d:%02d.%03d %7s ",
!             time->tm_year, time->tm_mon + 1, time->tm_mday,
              time->tm_hour, time->tm_min, time->tm_sec,
              (int) (tv.tv_usec/1000), pid);

--- 227,234 ----
      time = localtime(&tm);

      sprintf(pid, "[%d]", MyProcPid);
!     sprintf(timestamp, "%04d%02d%02d.%02d:%02d:%02d.%03d %7s ",
!             time->tm_year+1900, time->tm_mon + 1, time->tm_mday,
              time->tm_hour, time->tm_min, time->tm_sec,
              (int) (tv.tv_usec/1000), pid);


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ed Loehr
Дата:
Сообщение: pgsql y2k bug?
Следующее
От: Bruce Momjian
Дата:
Сообщение: Is DATEDEBUG useful