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(at)sai(dot)msu(dot)su>
> > To: hackers(at)postgreSQL(dot)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(at)sai(dot)msu(dot)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(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
> phone: +007(095)939-16-83, +007(095)939-23-83
>
>
>

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)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)