Обсуждение: macaddr stuff !

Hi,
 I have no one to turn to. I've tried here & there but got no answer. Why is there is a problem creating unique indices
onmacaddr columns even if there ARE NO (checked by count on distinct,group by) duplicated keys ?
 
 And finally :
 create table tmac (i int4,mac macaddr); insert int table tmac (i) values (1); insert int table tmac (i) values (2);
insertint table tmac (i) values (3); select * from tmac where mac='01:02:03:04:05:06';
 
 I get backend termination no matter if table has indices, is vacuumed , is new or even just after the postgres
instalation.
 HELP !
 Oh, I use 6.4.2 under i386 Redhat 5.2 Linux.

Pawel Pierscionek,

> Hi,
> 
>   I have no one to turn to. I've tried here & there but got no answer.
>   Why is there is a problem creating unique indices on macaddr columns even
>   if there ARE NO (checked by count on distinct,group by) duplicated keys ?
> 
>   And finally :
> 
>   create table tmac (i int4,mac macaddr);
>   insert int table tmac (i) values (1);
>   insert int table tmac (i) values (2);
>   insert int table tmac (i) values (3);
>   select * from tmac where mac='01:02:03:04:05:06';
> 

Yes, I can reproduce it here.  Looks like a bug.

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

> Hi,
> 
>   I have no one to turn to. I've tried here & there but got no answer.
>   Why is there is a problem creating unique indices on macaddr columns even
>   if there ARE NO (checked by count on distinct,group by) duplicated keys ?
> 
>   And finally :
> 
>   create table tmac (i int4,mac macaddr);
>   insert int table tmac (i) values (1);
>   insert int table tmac (i) values (2);
>   insert int table tmac (i) values (3);
>   select * from tmac where mac='01:02:03:04:05:06';

I have fixed the problem in the current development tree.  The problem
is nulls in that IP field.

I added PointerIsValid() checks to backend/utils/adt/mac.c.

This will be fixed in 6.5 beta.  This was a known problem with the INET
types, but I did not realize how bad it was.

[D'Arcy, I just added PointerIsValid() checks that were similar to other
type routines.]

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

Thus spake Bruce Momjian
> I have fixed the problem in the current development tree.  The problem
> is nulls in that IP field.
> 
> I added PointerIsValid() checks to backend/utils/adt/mac.c.
> 
> This will be fixed in 6.5 beta.  This was a known problem with the INET
> types, but I did not realize how bad it was.
> 
> [D'Arcy, I just added PointerIsValid() checks that were similar to other
> type routines.]

Yes, this was the issue I was mentioning to you the other day in IRC.
Remember I submitted a patch to network.c but we agreed that the proper
fix is higer up in the code.  The problem is that any function taking
a null arg should return null but in the code as it stands now we don't
check that until after the function has been called.  The result is that
we have all sorts of code in the package that has to deal with null
arguments just so the result can be thrown away after the function
returns.  What we need to do is identify the places where the function
is dispatched and deal with the null args there before calling them.  I
tried finding these places but it wasn't so easy.  Has anyone else been
looking at this part of the code?

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.