Thread: RE: [HACKERS] min() and max() causing aborts

I just did another cvs update and nothing was updated.  So, I have already
applied this patch, the path has not been committed in to cvs, or the patch
did not do it for me :-).
-----Original Message-----From:    Bruce Momjian [SMTP:maillist@candle.pha.pa.us]Sent:    Saturday, March 20, 1999 6:17
PMTo:   Michael DavisCc:    pgsql-hackers@postgreSQL.orgSubject:    Re: [HACKERS] min() and max() causing aborts
 
Fixed this morning at 8am EST.

> I recompiled everything several time, did an initdb each time,
reloaded my> database, and did a vacuum.  No I did not see anything in the
postmaster log> file. > > I updated my cvs tree this morning.   And rebuild everything
again.  I> deleted my data directory and in initdb followed by:> > createdb mp> psql -e < mp.out            -- dump
from6.4.2> Connection to database 'postgres' failed.> FATAL 1:  Database postgres does not exist in pg_database> > I
canteven load data with the lastest set of changes.  There are
 
no> messages in the postgres .log file or .err files.> > There are still failures in the regression tests:> > boolean
..ok> char .. ok> name .. ok> varchar .. ok> text .. ok> strings .. ok> int2 .. failed> int4 .. failed> int8 .. ok> oid
..ok> float4 .. ok> float8 .. failed> numerology .. ok> point .. ok> lseg .. ok> box .. ok> path .. ok> polygon .. ok>
circle.. ok> geometry .. failed> timespan .. ok> datetime .. ok> reltime .. ok> abstime .. ok> tinterval .. ok>
horology.. ok> inet .. ok> comments .. ok> opr_sanity .. ok> create_function_1 .. ok> create_type .. ok> create_table
..ok> create_function_2 .. ok> constraints .. ok> triggers .. failed> copy .. ok> create_misc .. ok> create_aggregate
..ok> create_operator .. ok> create_view .. ok> create_index .. ok> sanity_check .. ok> errors .. ok> select .. ok>
select_into.. ok> select_distinct .. ok> select_distinct_on .. ok> select_implicit .. ok> select_having .. failed>
subselect.. ok> union .. ok> case .. ok> join .. ok> aggregates .. failed> transactions .. ok> random .. ok> portals ..
ok>misc .. failed> arrays .. ok> btree_index .. ok> hash_index .. ok> select_views .. ok> alter_table .. ok> portals_p2
..ok> rules .. ok> limit .. ok> install_plpgsql .. ok> plpgsql .. ok> temp .. ok> > >     -----Original Message----->
 From:    Bruce Momjian [SMTP:maillist@candle.pha.pa.us]>     Sent:    Saturday, March 20, 1999 5:41 AM>     To:
MichaelDavis>     Cc:    pgsql-hackers@postgreSQL.org>     Subject:    Re: [HACKERS] min() and max() causing aborts> >
  > I pulled the latest version of the source tree yesterday
 
and> complied>     > PosgtreSQL 6.5.  The get the following error on any select> statement>     > containing min() and
max():>    > >     > mp=> select max(addressid) from addresses;>     > pqReadData() -- backend closed the channel
unexpectedly.>    >         This probably means the backend terminated
 
abnormally> before or>     > while processing the request.>     > We have lost the connection to the backend, so
further
processing> is>     > impossible.  Terminating.>     > >     > >     > I am running Red Hat 5.1.>     > >     > FYI, I
alsonoticed failures in the regressions tests for
 
int2 and> int4 and>     > some others (int8 was okay).  I did not dig very deep into
this> but the only>     > error I could see with int2 and int4 occurred when the
value that> was being>     > inserted into the table was too large for the field.  For
example,> inserting>     > 100000 into an int2 field.>     > > >     I recommend a clean compile and initdb to see if
thatfixes
 
it.  Do> you>     see anything in the postmaster log file?> >     -- >       Bruce Momjian                        |
http://www.op.net/~candle>       maillist@candle.pha.pa.us            |  (610) 853-3000>       +  If your life is a
harddrive,     |  830 Blythe Avenue>       +  Christ can be your backup.        |  Drexel Hill,
 
Pennsylvania> 19026> > 

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

[Charset iso-8859-1 unsupported, filtering to ASCII...]
> I just did another cvs update and nothing was updated.  So, I have already
> applied this patch, the path has not been committed in to cvs, or the patch
> did not do it for me :-).

All I can say is that I was getting the exact pattern of failures you
got until I backed out the patch.

Are other people now seeing aggregate failure.  If so, I will post the
remainder of the patch that is still installed to see if removing that
will help, thought the other part deals more with expressions than
aggregates.

I just tested and it shows as applied.  I am confused.

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

Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Are other people now seeing aggregate failure.  If so, I will post the
> remainder of the patch that is still installed to see if removing that
> will help, thought the other part deals more with expressions than
> aggregates.

Yesterday evening (after you partially backed out that patch) I updated
and rebuilt and ran regression test.  I didn't see any regress failures
involving aggregates, and a quick hand smoke-test of max and min looks
OK:

regression=> select max(f1) from float8_tbl;
max
--- 0
(1 row)

regression=> select min(f1) from float8_tbl;
min
---------------------
-1.2345678901234e+200
(1 row)

There were a couple of other things broken yesterday, but they didn't
seem related to Michael's problem.
        regards, tom lane

> Yesterday evening (after you partially backed out that patch) I updated
> and rebuilt and ran regression test.  I didn't see any regress failures
> involving aggregates, and a quick hand smoke-test of max and min looks
> OK:

I am attaching the patch I BACKED HOW, so the user can see if it is in
their tree.  It should not be ther.

--
  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
***
/afs/ece.cmu.edu/project/lcs/lcs-004/er1p/postgres/611/src/backend/executor/nodeAgg.c
Thu Mar 11 23:59:11 1999
---
/afs/ece.cmu.edu/project/lcs/lcs-004/er1p/postgres/612/src/backend/executor/nodeAgg.c
Fri Mar 19 15:01:21 1999
***************
*** 110,115 ****
--- 110,116 ----
                  isNull2 = FALSE;
      bool        qual_result;

+     Datum  oldVal = (Datum) NULL;  /* XXX - so that we can save and free on each iteration - er1p */

      /* ---------------------
       *    get state info from node
***************
*** 372,379 ****
--- 373,382 ----
                           */
                          args[0] = value1[aggno];
                          args[1] = newVal;
+                         oldVal = value1[aggno]; /* XXX - save so we can free later - er1p */
                          value1[aggno] =    (Datum) fmgr_c(&aggfns->xfn1,
                                             (FmgrValues *) args, &isNull1);
+                         pfree(oldVal); /* XXX - new, let's free the old datum - er1p */
                          Assert(!isNull1);
                      }
                  }

> I am attaching the patch I BACKED HOW, so the user can see if it is in
> their tree.  It should not be ther.

I see the problem with that patch: it's assuming that the old value is
necessarily a pointer to something.  For pass-by-value types (eg int4),
it ain't.
        regards, tom lane