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 also noticed 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 that fixes 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 hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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.

It was my commit of someone's memory cleanups yesterday that broke it.
I will check into it.

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

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 have backed out the part of the patch I think was the problem.

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

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 from 6.4.2
Connection to database 'postgres' failed.
FATAL 1: Database postgres does not exist in pg_database

I cant even 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: Michael Davis
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 also noticed 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 that fixes 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 hard drive,     |  830 Blythe Avenue
	  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania
19026

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 from 6.4.2
Connection to database 'postgres' failed.
FATAL 1: Database postgres does not exist in pg_database

I cant even 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: Michael Davis
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 also noticed 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 that fixes 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 hard drive,     |  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

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 PM
To: Michael Davis
Cc: pgsql-hackers@postgreSQL.org
Subject: 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 from 6.4.2
Connection to database 'postgres' failed.
FATAL 1: Database postgres does not exist in pg_database

I cant even 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: Michael Davis
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 also noticed 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 that fixes

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 hard drive,     |  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, Pennsylvania 19026

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

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

Min() and max() are now working, thank you. Create User causes the back end
to abort:

select * from pg_shadow;
usename
|usesysid|usecreatedb|usetrace|usesuper|usecatupd|passwd|valuntil

--------+--------+-----------+--------+--------+---------+------+-----------
-----------------
postgres| 501|t |t |t |t |
|Fri Jan 30 23:00:00 2037 MST
(1 row)

create user kari;
ERROR: Bad abstime external representation ''

select * from pg_shadow;
NOTICE: (transaction aborted): queries ignored until END
*ABORT STATE*

Interesting to note that with 6.4.2 everything worked last night. This
morning, all ODBC client get a permission denied message. I can log using
psql but not with any ODBC client. The only change I made was installing a
new printer.

Still some regression test failures:

int2 .. failed
int4 .. failed
geometry .. failed
triggers .. failed

I am not sure I have the cvs update thing correct. I had to cd into the
directory containing nodeAgg.c and do a cvs update to get this downloaded.
How come a cvs update from my pgsql/src directory did not pull all updated
sources?

Thanks, Michael

-----Original Message-----
From: Bruce Momjian [SMTP:maillist@candle.pha.pa.us]
Sent: Sunday, March 21, 1999 11:59 AM
To: tgl@sss.pgh.pa.us
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] min() and max() causing aborts

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 << File: /wrk/tmp2/nodeAgg.c.diff >>  << File: ATT26249.ATT >>