Re: [HACKERS] pgsql y2k bug?

> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026