Postgres Pro
Downloads
Home   >   mailing lists

Thread: pgsql y2k bug?

pgsql y2k bug?

From
Ed Loehr
Date:
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...

% date
Sat Jan  1 18:24:20 CST 2000

AFAICT, this is limited to the logging mechanism (datetime output
appears fine).

Cheers,
Ed Loehr

Re: [HACKERS] pgsql y2k bug?

From
Bruce Momjian
Date:
> 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);

Re: [HACKERS] pgsql y2k bug?

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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 you are going to go to 4-digit years in timestamps, I think you also
need to increase the TIMESTAMP_SIZE constant used by elog.c when
ELOG_TIMESTAMPS is set.

An alternative solution is to print time->tm_year % 100.

Either of these solutions might break existing programs that analyze
logfiles, if any there be...
        regards, tom lane

Re: [HACKERS] pgsql y2k bug?

From
Bruce Momjian
Date:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > 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 you are going to go to 4-digit years in timestamps, I think you also
> need to increase the TIMESTAMP_SIZE constant used by elog.c when
> ELOG_TIMESTAMPS is set.
> 
> An alternative solution is to print time->tm_year % 100.
> 
> Either of these solutions might break existing programs that analyze
> logfiles, if any there be...

Done.  Length increased by 2 from 28 to 30.

--  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,
Pennsylvania19026