Re: Bug in libpq causes local clients to hang
От | Jeffrey Baker |
---|---|
Тема | Re: Bug in libpq causes local clients to hang |
Дата | |
Msg-id | fd145f7d0803240937q6fe18310red61a78f214c0206@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Bug in libpq causes local clients to hang (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Bug in libpq causes local clients to hang
|
Список | pgsql-hackers |
On Mon, Mar 24, 2008 at 9:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Jeffrey Baker" <jwbaker@gmail.com> writes: > > On Sun, Mar 23, 2008 at 8:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > >> If it works over TCP and not over Unix socket, it's a kernel bug. > >> The libpq code doesn't really know the difference after connection > >> setup. > > > The same thought occurred to me, but it could also be a race condition > > which the unix socket is fast enough to trigger but the TCP socket is > > not fast enough to trigger. I'm peeking around in the code but > > nothing jumps out yet. > > Fairly hard to believe given that you're talking about communication > between two sequential processes. Anyway I'd suggest that the first > thing to do is extract a reproducible test case. It'd be useful > to see if it hangs on other platforms... The stack trace doesn't actually make sense, does it? I think that (at least) the PQmblen frame is spurious. -jwb
В списке pgsql-hackers по дате отправления: