Re: PrepareStatement.execute() blocked because of long time'create index' operation, connection leak

Поиск
Список
Период
Сортировка
От Vladimir Sitnikov
Тема Re: PrepareStatement.execute() blocked because of long time'create index' operation, connection leak
Дата
Msg-id CAB=Je-Hop9x03hvwLOoeONGtCCRzybw=GDLfGC9bZz0v0tfGSg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PrepareStatement.execute() blocked because of long time 'create index' operation, connection leak  (Vitalii Tymchyshyn <vit@tym.im>)
Список pgsql-jdbc
Vitalii>But do we already use SO_KEEPALIVE on the socket layer?
Vitalii>Also I am not really sure socket was closed on the server end.
Vitalii> TS said he could see server backend in the idle state. Also backed server did not fail, so unless there were some  network glitch we should have received tcp reset.

tcpKeepAlive connection setting is false by default. I think it's better to make "true" the default value.

Sehrope>I don't think it's a good idea to flood the server with dummy messages for the purposes of keeping the connection alive.
Sehrope>Besides the usual problems of filling up the send buffer, you'd also have to have it done in a separate thread
Sehrope>as the usual sender is already blocked waiting for the command response.

Sending a sync message once every 10m will hardly fill up the buffers.
On the other hand, it could make the connection more resilient.

Having several threads for (e.g. one for read and one for write) would resolve "deadlock out of buffers got full" issue, so it is good no matter if we add "ping" there.

Vladimir

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

Предыдущее
От: Vitalii Tymchyshyn
Дата:
Сообщение: Re: PrepareStatement.execute() blocked because of long time'create index' operation, connection leak
Следующее
От: "jingzhi.zhang@outlook.com"
Дата:
Сообщение: Re: PrepareStatement.execute() blocked because of long time 'create index' operation, connection leak