Re: killing pg_dump leaves backend process
| От | Jeff Janes |
|---|---|
| Тема | Re: killing pg_dump leaves backend process |
| Дата | |
| Msg-id | CAMkU=1wCf9LeQXRge1ty9uDHEQRi2v9Mpe2Pox1xVdG6TZ2XcA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: killing pg_dump leaves backend process (Greg Stark <stark@mit.edu>) |
| Ответы |
Re: killing pg_dump leaves backend process
|
| Список | pgsql-hackers |
On Sat, Aug 10, 2013 at 4:26 AM, Greg Stark <stark@mit.edu> wrote: > > The problem is that I don't know of any way to detect eof on a socket > other than trying to read from it (or calling poll or select). So the > server would have to periodically poll the client even when it's not > expecting any data. The inefficiency is annoying enough and it still > won't detect the eof immediately. Do we know how inefficient it is, compared to the baseline work done by CHECK_FOR_INTERRUPTS() and its affiliated machinery? ... > > I'm surprised this is the first time we're hearing people complain > about this. I know I've seen similar behaviour from Mysql and thought > to myself that represented pretty poor behaviour and assumed Postgres > did better. I've seen other complaints about it (and made at least one myself) Cheers, Jeff
В списке pgsql-hackers по дате отправления: