Re: We do not need pg_promote_v4_to_v6_addr/mask

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: We do not need pg_promote_v4_to_v6_addr/mask
Дата
Msg-id 25028.1424138854@sss.pgh.pa.us
обсуждение исходный текст
Ответ на We do not need pg_promote_v4_to_v6_addr/mask  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: We do not need pg_promote_v4_to_v6_addr/mask  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
I wrote:
> We have some code in the server that attempts to match IPv4 address
> entries in pg_hba.conf to incoming connections that are in IPv6 protocol
> but have addresses in the range ::ffff:xxxx:xxxx (the IPv4-in-IPv6
> subrange).  As revealed by today's bug report from Hugo Osvaldo Barrera,
> this code has been broken since commit f3aec2c7f51904e7 (shipped in 9.0),
> as a result of sloppiness with a memcpy() source address.  How is it that
> nobody noticed?

BTW, a bit of digging in the git logs and mail archives says that the code
in question was originally added in 7.4 (commit 3c9bb8886df7d56a), in
response to this discussion:
http://www.postgresql.org/message-id/flat/200309012156.05874.t.maekitalo@epgmbh.de

So back in 2003 there were Linux boxes that actively transformed IPv4
connection addresses to ::ffff:xxxx:xxxx format.  Current Linux behavior
is the exact opposite: even if you try to say ::ffff:xxxx:xxxx in a
connection request, IPv4 is what comes out the other end.  I find the same
on current OS X btw.  So I'm definitely now of the opinion that this is a
workaround for a long-deceased Linux kernel bug, and not something we need
to continue^X^X^Xresume supporting.
        regards, tom lane



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

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: Add min and max execute statement time in pg_stat_statement
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: Add min and max execute statement time in pg_stat_statement