Re: Stats Collector Error 7.4beta1 and 7.4beta2

Поиск
Список
Период
Сортировка
От
Тема Re: Stats Collector Error 7.4beta1 and 7.4beta2
Дата
Msg-id 2556.24.211.141.25.1062810559.squirrel@www.dunslane.net
обсуждение исходный текст
Ответ на Re: Stats Collector Error 7.4beta1 and 7.4beta2  (Jan Wieck <JanWieck@Yahoo.com>)
Ответы Re: Stats Collector Error 7.4beta1 and 7.4beta2  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
This analysis makes sense - I think using memcmp is clearly wrong here.

cheers

andrew

Jan Wieck said:
> On a second thought,
>
> I still believe that this is just garbage in the padding bytes after
> the  IPV4 address. The code currently bind()'s and connect()'s
> explicitly to  an AF_INET address. So all we ever should see is
> something from and  AF_INET address. Everything else in the sin_family
> has to be discarded.  I do not think it is allowed to bind() and
> connect() to an IPV4 address  and then get anything other than an IPV4
> address back from the system.  If that is the case, the whole idea is
> broken.
>
> An AF_INET address now has only two relevant fields, the sin_port and
> sin_addr. If they are the same, everything is fine. So the correct
> check  would be that 1. fromlen > sizeof(sin_family), 2. sin_family ==
> AF_INET,  3. sin_port and sin_addr identical.
>
> After reading Kurt's quoting of the SUS manpage I have to agree with
> Tom  in that we cannot skip the check entirely. It says it limits for
> recv()  but we are using recvfrom() ... there might be a little
> difference on  that platform ...
>
>





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Notices for redundant operations
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Stats Collector Error 7.4beta1 and 7.4beta2