Return-Path: frank@odf.UCSD.EDU 
Delivery-Date: Thu, 07 Jul 94 12:05:05 -0700
Return-Path: frank@odf.UCSD.EDU
Received: from hofmann.CS.Berkeley.EDU (hofmann.CS.Berkeley.EDU [128.32.131.12]) by nobozo.CS.Berkeley.EDU (8.6.4/8.6.3) with ESMTP id MAA22959 for <aoki@postgres.Berkeley.EDU>; Thu, 7 Jul 1994 12:05:05 -0700
Received: from ucsd.edu (ucsd.edu [132.239.254.201]) by hofmann.CS.Berkeley.EDU (8.6.8/8.6.6.Beta11) with ESMTP id MAA05961 for <aoki@CS.Berkeley.EDU>; Thu, 7 Jul 1994 12:05:03 -0700
Received: from odf by ucsd.edu; id MAA24845
	sendmail 8.6.9/UCSD-2.2-sun via SMTP
	Thu, 7 Jul 1994 12:05:00 -0700 for <aoki@CS.Berkeley.EDU>
Received: by odf (5.0/SMI-SVR4)
	id AA29343; Thu, 7 Jul 1994 12:00:44 +0800
Date: Thu, 7 Jul 1994 12:00:44 +0800
From: frank@odf.UCSD.EDU (Frank Delahoyde)
Message-Id: <9407071900.AA29343@odf>
To: aoki@CS.Berkeley.EDU
Subject: Re: postgres v4r2
X-Sun-Charset: US-ASCII
content-length: 2448

Paul,

The bug you mentioned:

> oh, wait.  there is a flaky bug on solaris using
> sunpro cc (but not, as far as i have seen, gcc); you may see
> 
> Query sent to backend is "retrieve (max_3_7 = float8max{student.gpa}) "
> ---------------
> | max_3_7     |
> ---------------
> | 3.1         |
> ---------------
> 
> in regress.out.  i haven't tracked that down -- i've only had a couple 
> of days to play with the sunpro compiler.

isn't a Solaris problem. Solaris just has SVR4 malloc which has a nasty habit
of overwritting free'd storage. If you link the backend with -lmalloc (a
different storage allocation policy) it goes away.

The real problem is in src/backend/executor/n_aggregate.c (ExecAgg), where
TupleTableSlots are being reused (and the tuples pfree'd) while they are still
in-use.

My hack:

*** n_aggregate.c.orig	Thu Jul  7 11:31:24 1994
--- n_aggregate.c	Thu Jul  7 11:30:40 1994
***************
*** 61,67 ****
  	Plan			outerNode;
  	HeapTuple		outerTuple, newTuple, aggTuple;
  	TupleDescriptor		outerTupDesc, aggtupdesc;
! 	TupleTableSlot		outerslot, newSlot;
  	char	 		nulls = ' ';
  	Relation		tempRelation;
  	String	 		aggname;
--- 61,67 ----
  	Plan			outerNode;
  	HeapTuple		outerTuple, newTuple, aggTuple;
  	TupleDescriptor		outerTupDesc, aggtupdesc;
! 	TupleTableSlot		outerslot, newSlot, xfn1Slot;
  	char	 		nulls = ' ';
  	Relation		tempRelation;
  	String	 		aggname;
***************
*** 134,139 ****
--- 134,140 ----
  		if (isNull2)
  			elog(WARN, "ExecAgg: agginitval2 is null");
  	}
+ 	xfn1Slot = NULL;
  	if (ObjectIdIsValid(xfn1_oid)) {
  		fmgr_info(xfn1_oid, &xfn1_ptr, &xfn1_nargs);
  		xfn1_val = AggNameGetInitVal(aggname,
***************
*** 157,162 ****
--- 158,165 ----
  				SlotTupleDescriptor(outerslot);
  			xfn1_val = fastgetattr(outerTuple, 1, outerTupDesc,
  					       &isNull1);
+ 			xfn1Slot = outerslot;
+ 			ExecSetSlotPolicy(xfn1Slot, FALSE);
  
  			if (ObjectIdIsValid(xfn2_oid)) {
  				xfn2_val = fmgr_c(xfn2_ptr, xfn2_oid,
***************
*** 198,203 ****
--- 201,208 ----
  		}
  		++nTuplesAgged;
  	}
+ 	if (xfn1Slot)
+ 	    ExecSetSlotPolicy(xfn1Slot, TRUE);
  
  	/* --------------
  	 * finalize the aggregate (if necessary), and get the resultant value

--
         Frank M. Delahoyde | Phone: 619.534.1901
 Scripps Inst. Oceanography | Fax:   619.534.7383
Oceanographic Data Facility | omnet: SCRIPPS.STS
   La Jolla, Ca. 92093-0214 | Email: frank@odf.ucsd.edu