Backends hanging around (was Re: Number of open files)
От | Tom Lane |
---|---|
Тема | Backends hanging around (was Re: Number of open files) |
Дата | |
Msg-id | 10045.981594266@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Number of open files (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
I wrote: > "Mark Alliban" <MarkA@idnltd.com> writes: >> Also backends seem to hang around for about a minute after I close >> the ODBC connections. Is this normal? > Seems odd to me too. How reproducible is that behavior --- does it happen for all connections, or only a few? Is the time before disconnection consistent? I've just noticed and repaired a bug that might explain this misbehavior, but only if the behavior is not as consistent as you imply. The bug I found is that if a connection request is completed and a backend is forked off while other connection request(s) are in progress, the new child backend has an open file descriptor for the other client connection(s) as well as its own. It will never touch the other clients' descriptors, but simply having them might affect the kernel's behavior. In particular, if another client performs its tasks and exits without sending a disconnect message --- which ODBC doesn't send --- then I think the backend spawned for the other client wouldn't be told the connection is closed until the first one exits and its descriptor for the connection is discarded. You could check into this possibility with a tool like lsof: when you see a backend hanging around with no client, look to see if any other backends have open file descriptors for the same connection. regards, tom lane
В списке pgsql-general по дате отправления: