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


Sat, 01 Jan 2000 18:28:20 -0600
Ed Loehr <eloehr@austin.rr.com>
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@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);
Sat, 1 Jan 2000 20:42:57 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] pgsql y2k bug?
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

Sat, 01 Jan 2000 21:06:22 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] pgsql y2k bug? 
> 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, Pennsylvania 19026

Sat, 1 Jan 2000 21:10:32 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] pgsql y2k bug?