Re: Stats Collector Error 7.4beta1 and 7.4beta2

From: Kevin Brown <kevin(at)sysexperts(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Stats Collector Error 7.4beta1 and 7.4beta2
Date: 2003-09-09 09:10:20
Message-ID: 20030909091020.GD3845@filer
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> <andrew(at)dunslane(dot)net> writes:
> > This analysis makes sense - I think using memcmp is clearly wrong here.
>
> Yeah, now that I think about it, we're betting on the kernel to
> faithfully zero all unused bits in addrinfo structures. In an ideal
> world, all kernels would do that, but in the real world it seems like
> a losing bet.

Yeah, I've always been under the impression that it's a bad idea in
general to memcmp() structs, if only because in doing so you make a
lot of implicit assumptions about the structs in question that aren't
necessarily true, especially when dealing with multiple architectures.

Makes me wonder if there are other parts of the code where we're
vulnerable to the same sort of issue...

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

--
Kevin Brown kevin(at)sysexperts(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Achilleus Mantzios 2003-09-09 12:07:12 Re: undefine currval()
Previous Message R. van Twisk 2003-09-09 06:43:47 Re: plpgsql doesn't coerce boolean expressions to boolean