Re: [PATCHES] [HACKERS] Followup on the UnixWare Optimizer bug.

2005-08-24 Thread Bruce Momjian
Larry Rosenman wrote:
 The following is from my SCO Internal contact about the bug.  It's
 definitely their bug.  Towards the end of the
 Exact diagnosis, is a suggested work-around for now, as well as a (possible)
 memory leak.
...
 Also note that there appears to be a memory leak in the interval_
 routines.  For example interval_div() allocates a result Interval.
 It eventually passes this result through to interval_justify_hours() which
 allocates another Interval result and that result is what gets passed
 back to caller on interval_div().  The 1st Interval allocated appears to be
 left around...

Good catch on the memory leak.  I have applied the following fix. 
Thanks to SCO for the report.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/func.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/func.sgml,v
retrieving revision 1.282
diff -c -c -r1.282 func.sgml
*** doc/src/sgml/func.sgml  24 Aug 2005 20:49:35 -  1.282
--- doc/src/sgml/func.sgml  25 Aug 2005 01:26:36 -
***
*** 5189,5194 
--- 5189,5200 
  /table
  
 para
+ If you are using both functionjustify_hours/ and 
functionjustify_days/,
+ it is best to use functionjustify_hours/ first so any additional days 
will
+ justified by functionjustify_days/.
+/para
+ 
+para
  In addition to these functions, the SQL literalOVERLAPS/ operator is
  supported:
  synopsis
Index: src/backend/utils/adt/timestamp.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/adt/timestamp.c,v
retrieving revision 1.148
diff -c -c -r1.148 timestamp.c
*** src/backend/utils/adt/timestamp.c   12 Aug 2005 18:23:54 -  1.148
--- src/backend/utils/adt/timestamp.c   25 Aug 2005 01:26:39 -
***
*** 1892,1898 
  {
Timestamp   dt1 = PG_GETARG_TIMESTAMP(0);
Timestamp   dt2 = PG_GETARG_TIMESTAMP(1);
!   Interval   *result;
  
result = (Interval *) palloc(sizeof(Interval));
  
--- 1892,1898 
  {
Timestamp   dt1 = PG_GETARG_TIMESTAMP(0);
Timestamp   dt2 = PG_GETARG_TIMESTAMP(1);
!   Interval   *result, *result2;
  
result = (Interval *) palloc(sizeof(Interval));
  
***
*** 1914,1922 
result-month = 0;
result-day = 0;
  
!   result = DatumGetIntervalP(DirectFunctionCall1(interval_justify_hours,

IntervalPGetDatum(result)));
!   PG_RETURN_INTERVAL_P(result);
  }
  
  /*interval_justify_hours()
--- 1914,1923 
result-month = 0;
result-day = 0;
  
!   result2 = DatumGetIntervalP(DirectFunctionCall1(interval_justify_hours,

IntervalPGetDatum(result)));
!   pfree(result);
!   PG_RETURN_INTERVAL_P(result2);
  }
  
  /*interval_justify_hours()
***
*** 2263,2269 
Interval   *span = PG_GETARG_INTERVAL_P(0);
float8  factor = PG_GETARG_FLOAT8(1);
double  month_remainder, day_remainder;
!   Interval   *result;
  
result = (Interval *) palloc(sizeof(Interval));
  
--- 2264,2270 
Interval   *span = PG_GETARG_INTERVAL_P(0);
float8  factor = PG_GETARG_FLOAT8(1);
double  month_remainder, day_remainder;
!   Interval   *result, *result2;
  
result = (Interval *) palloc(sizeof(Interval));
  
***
*** 2289,2297 
day_remainder * SECS_PER_DAY);
  #endif
  
!   result = DatumGetIntervalP(DirectFunctionCall1(interval_justify_hours,

IntervalPGetDatum(result)));
!   PG_RETURN_INTERVAL_P(result);
  }
  
  Datum
--- 2290,2299 
day_remainder * SECS_PER_DAY);
  #endif
  
!   result2 = DatumGetIntervalP(DirectFunctionCall1(interval_justify_hours,

IntervalPGetDatum(result)));
!   pfree(result);
!   PG_RETURN_INTERVAL_P(result2);
  }
  
  Datum
***
*** 2310,2316 
Interval   *span = PG_GETARG_INTERVAL_P(0);
float8  factor = PG_GETARG_FLOAT8(1);
double  month_remainder, day_remainder;
!   Interval   *result;
  
result = (Interval *) palloc(sizeof(Interval));
  
--- 2312,2318 
Interval   *span = PG_GETARG_INTERVAL_P(0);
  

Re: [PATCHES] [HACKERS] Followup on the UnixWare Optimizer bug.

2005-08-24 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes:
 Good catch on the memory leak.  I have applied the following fix. 

These explicit pfrees are a waste of time, and probably actually
counterproductive as far as speed goes, because these functions
will always be invoked in relatively short-lived memory contexts.

I wouldn't object except that they seem to make the code noticeably
more obscure.

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly