weird problem with latest cvs

Started by Oleg Bartunovover 27 years ago9 messageshackers

Jump to latest

Oleg Bartunov

oleg@sai.msu.su

over 27 years ago

Hi,

just updated development version from cvs and got strange problem :

select * from WORK_FLATS where DISTRICT_ID in (4,101);
select * from WORK_FLATS where DISTRICT_ID in (101,4);

Does anyone understand what's the difference between this two selects ?

explain produces the same plans:
Index Scan using wfidx_district_id on work_flats (cost=6.90 size=29 width=132)
but first select works fine while second fails with message:
flats=> select * from WORK_FLATS where DISTRICT_ID in (101,4);
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.

6.3.2+patches works ok !!!

Regards,

Oleg

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

Oleg Bartunov

oleg@sai.msu.su

over 27 years ago

In reply to: Oleg Bartunov (#1)

Re: [HACKERS] weird problem with latest cvs

It seems this happens only if
select * from WORK_FLATS where DISTRICT_ID=101
produces zero result ^^^
and
select * from WORK_FLATS where DISTRICT_ID=4
^
produces non-zero result

Below is an example:

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (101);
count
-----
0
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (100);
count
-----
0
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (100,101);
count
-----
0
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (0);
count
-----
4
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (101,0);
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.

Oleg

On Tue, 18 Aug 1998, Oleg Bartunov wrote:

Date: Tue, 18 Aug 1998 23:27:57 +0400 (MSK DST)
From: Oleg Bartunov <oleg@sai.msu.su>
To: hackers@postgreSQL.org
Subject: [HACKERS] weird problem with latest cvs

Hi,

just updated development version from cvs and got strange problem :

select * from WORK_FLATS where DISTRICT_ID in (4,101);
select * from WORK_FLATS where DISTRICT_ID in (101,4);

Does anyone understand what's the difference between this two selects ?

explain produces the same plans:
Index Scan using wfidx_district_id on work_flats (cost=6.90 size=29 width=132)
but first select works fine while second fails with message:
flats=> select * from WORK_FLATS where DISTRICT_ID in (101,4);
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.

6.3.2+patches works ok !!!

Regards,

Oleg

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

Bruce Momjian

bruce@momjian.us

over 27 years ago

In reply to: Oleg Bartunov (#2)

Re: [HACKERS] weird problem with latest cvs

I am able to reproduce the bug. Looks like some problem with the
indexing or OR's. I will check into it.

It seems this happens only if
select * from WORK_FLATS where DISTRICT_ID=101
produces zero result ^^^
and
select * from WORK_FLATS where DISTRICT_ID=4
^
produces non-zero result

Below is an example:

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (101);
count
-----
0
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (100);
count
-----
0
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (100,101);
count
-----
0
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (0);
count
-----
4
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (101,0);
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.

Oleg

On Tue, 18 Aug 1998, Oleg Bartunov wrote:

Date: Tue, 18 Aug 1998 23:27:57 +0400 (MSK DST)
From: Oleg Bartunov <oleg@sai.msu.su>
To: hackers@postgreSQL.org
Subject: [HACKERS] weird problem with latest cvs

Hi,

just updated development version from cvs and got strange problem :

select * from WORK_FLATS where DISTRICT_ID in (4,101);
select * from WORK_FLATS where DISTRICT_ID in (101,4);

Does anyone understand what's the difference between this two selects ?

explain produces the same plans:
Index Scan using wfidx_district_id on work_flats (cost=6.90 size=29 width=132)
but first select works fine while second fails with message:
flats=> select * from WORK_FLATS where DISTRICT_ID in (101,4);
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.

6.3.2+patches works ok !!!

Regards,

Oleg

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Bruce Momjian

bruce@momjian.us

over 27 years ago

In reply to: Oleg Bartunov (#2)

Re: [HACKERS] weird problem with latest cvs

It is my code that tries to check if a new row was matched by a previous
index, and hence discard it. If the previous index did not return any
rows, the slot is NULL, and it crashes. I will try to work on a fix.

It seems this happens only if
select * from WORK_FLATS where DISTRICT_ID=101
produces zero result ^^^
and
select * from WORK_FLATS where DISTRICT_ID=4
^
produces non-zero result

Below is an example:

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (101);
count
-----
0
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (100);
count
-----
0
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (100,101);
count
-----
0
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (0);
count
-----
4
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (101,0);
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.

Oleg

On Tue, 18 Aug 1998, Oleg Bartunov wrote:

Date: Tue, 18 Aug 1998 23:27:57 +0400 (MSK DST)
From: Oleg Bartunov <oleg@sai.msu.su>
To: hackers@postgreSQL.org
Subject: [HACKERS] weird problem with latest cvs

Hi,

just updated development version from cvs and got strange problem :

select * from WORK_FLATS where DISTRICT_ID in (4,101);
select * from WORK_FLATS where DISTRICT_ID in (101,4);

Does anyone understand what's the difference between this two selects ?

explain produces the same plans:
Index Scan using wfidx_district_id on work_flats (cost=6.90 size=29 width=132)
but first select works fine while second fails with message:
flats=> select * from WORK_FLATS where DISTRICT_ID in (101,4);
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.

6.3.2+patches works ok !!!

Regards,

Oleg

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Bruce Momjian

bruce@momjian.us

over 27 years ago

In reply to: Oleg Bartunov (#2)

Re: [HACKERS] weird problem with latest cvs

I fixed this problem this morning, and the current sources contain the
fix.

Thanks for the report.

It seems this happens only if
select * from WORK_FLATS where DISTRICT_ID=101
produces zero result ^^^
and
select * from WORK_FLATS where DISTRICT_ID=4
^
produces non-zero result

Below is an example:

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (101);
count
-----
0
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (100);
count
-----
0
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (100,101);
count
-----
0
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (0);
count
-----
4
(1 row)

flats=> select count(*) from WORK_FLATS where DISTRICT_ID in (101,0);
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.

Oleg

On Tue, 18 Aug 1998, Oleg Bartunov wrote:

Date: Tue, 18 Aug 1998 23:27:57 +0400 (MSK DST)
From: Oleg Bartunov <oleg@sai.msu.su>
To: hackers@postgreSQL.org
Subject: [HACKERS] weird problem with latest cvs

Hi,

just updated development version from cvs and got strange problem :

select * from WORK_FLATS where DISTRICT_ID in (4,101);
select * from WORK_FLATS where DISTRICT_ID in (101,4);

Does anyone understand what's the difference between this two selects ?

explain produces the same plans:
Index Scan using wfidx_district_id on work_flats (cost=6.90 size=29 width=132)
but first select works fine while second fails with message:
flats=> select * from WORK_FLATS where DISTRICT_ID in (101,4);
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.

6.3.2+patches works ok !!!

Regards,

Oleg

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Bruce Momjian

bruce@momjian.us

over 27 years ago

In reply to: Bruce Momjian (#5)

Re: [HACKERS] weird problem with latest cvs

Just tried latest cvs and initdb hangs:
initdb: creating template database in /usr/local/pgsql/data/base/template1

Creating global classes in /base

Adding template1 database to pg_database...

vacuuming template1
creating public pg_user view
Hangup

Do I need 'make distclean' first ?

Oleg

No, just a make clean. There is a problem with loading pg_description
from initdb, and I think I have the fix. Will post when it is updated.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Import Notes

Reply to msg id not found: Pine.GSO.3.96.SK.980820092035.1103A-100000@ra | Resolved by subject fallback

Jan Wieck

JanWieck@Yahoo.com

over 27 years ago

In reply to: Bruce Momjian (#6)

Re: [HACKERS] weird problem with latest cvs

Creating global classes in /base

Adding template1 database to pg_database...

vacuuming template1
creating public pg_user view
Hangup

Do I need 'make distclean' first ?

Oleg

No, just a make clean. There is a problem with loading pg_description
from initdb, and I think I have the fix. Will post when it is updated.

--
Bruce Momjian | 830 Blythe Avenue

Sorry, but it happens between the two echos for pg_user and
description. So it must be the pg_user creation that fails.

Jan

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

Oleg Bartunov

oleg@sai.msu.su

over 27 years ago

In reply to: Bruce Momjian (#6)

Re: [HACKERS] weird problem with latest cvs

Bruce,

vacuum still hangs up after you patch the cvs:
We are initializing the database system with username postgres (uid=505).
This user will own all the files and must also own the server process.

Creating Postgres database system directory /usr/local/pgsql/data

Creating Postgres database system directory /usr/local/pgsql/data/base

Creating template database in /usr/local/pgsql/data/base/template1

Creating global classes in /base

Adding template1 database to pg_database...

vacuuming template1
creating public pg_user view
Hangup

Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

Bruce Momjian

bruce@momjian.us

over 27 years ago

In reply to: Oleg Bartunov (#8)

Re: [HACKERS] weird problem with latest cvs

Bruce,

vacuum still hangs up after you patch the cvs:
We are initializing the database system with username postgres (uid=505).
This user will own all the files and must also own the server process.

Creating Postgres database system directory /usr/local/pgsql/data

Creating Postgres database system directory /usr/local/pgsql/data/base

Creating template database in /usr/local/pgsql/data/base/template1

Creating global classes in /base

Adding template1 database to pg_database...

vacuuming template1
creating public pg_user view
Hangup

OK, comment out the pg_user stuff and the rest of the initdb file, and
run it. You should then be able to start the postmaster and run psql on
the template1 database. See what works and what doesn't.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)