Re: BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram
От | Alvaro Herrera |
---|---|
Тема | Re: BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram |
Дата | |
Msg-id | 1345870202-sup-3003@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-bugs |
Excerpts from Robert Haas's message of s=C3=A1b ago 25 00:10:57 -0400 201= 2: > > It looks sane to me in a quick once-over (bearing in mind I can't tes= t > > it). What's bothering you about the ereport calls? >=20 > Well, 9.1 currently has: >=20 > errmsg_internal("failed to enumerate network events: %i", (int) GetLast= Error())) >=20 > Prior to your patch, master had: >=20 > errmsg_internal("failed to enumerate network events: error code %lu", > GetLastError()) >=20 > And you changed it to: >=20 > elog(ERROR, "failed to enumerate network events: error code %u", > WSAGetLastError()) >=20 > So obviously there's a conflict there. In the previously-posted > version, I chose to just take your version, but I'm not sure whether > it would be better -- in the back branches -- to simply replace > GetLastError() with WSAGetLastError() and leave it alone otherwise. Note that for translations none of this matters, because errmsg_internal() does not mark its argument for translation, and neither does elog(). The change of %i to "error code %lu" was done recently (during 9.2 devel cycle) to make all error messages involving GetLastError() consistent; see commit 1af55e275. --=20 =C3=81lvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-bugs по дате отправления: