Re: Stats Collector Error 7.4beta1 and 7.4beta2 - Mailing list pgsql-hackers

From Kurt Roeckx
Subject Re: Stats Collector Error 7.4beta1 and 7.4beta2
Date
Msg-id 20030909180341.GA6557@ping.be
Whole thread Raw
In response to Re: Stats Collector Error 7.4beta1 and 7.4beta2  (Kevin Brown <kevin@sysexperts.com>)
Responses Re: Stats Collector Error 7.4beta1 and 7.4beta2  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
On Tue, Sep 09, 2003 at 02:10:20AM -0700, Kevin Brown wrote:
> > I could go for Jan's idea of putting a random key into the messages,
> > if anyone feels that we should not trust to the kernel to enforce the
> > packet source address restriction.  But the memcmp() test seems a clear
> > loser given today's discussions.
> 
> The test in the 7.3.x code looked reasonable to me, especially if it's
> possible to make it work with IPV6 (if it doesn't already).  It's doing
> basically the right thing, at any rate: directly comparing the actual
> fields that are relevant.  Does this test represent a significant
> performance hit?

The reason I used a memcmp() instead of dealing with the
structure members themself is because it was easier.

Checking that they're the same address family is easy, and if
they're different the kernel is really broken.

For the addresses and port, in case of IPv4, you have to cast it
to sockaddr_in *, and compare the sin_addr and sin_port like
before.
For IPv6 you could do it with a memcmp on the sin6_addr part, and
put it inside an #ifdef HAVE_IPV6.

If you want to write code to compare 2 addresses, please make it
a general function and place it in ip.c.

Anyway, I'm happy with the current use of recv().


Kurt



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: libpq++
Next
From: Bruce Momjian
Date:
Subject: Re: Maximum table size