You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Do a blocking flush every 100 calls to put_copy_data
We had a blocking flush in pg-1.3.x at every call to put_copy_data.
This made sure, that all data is sent until the next put_copy_data.
In #462 (and pg-1.4.0 to .2) the behaviour was changed to rely on the non-blocking flushs libpq is doing internally.
This makes a decent performance improvement especially on Windows.
Unfortunately #473 proved that memory bloat can happen, when sending the data is slower than calls to put_copy_data happen.
As a trade-off this proposes to do a blocking flush only every 100 calls.
If libpq is running in blocking mode (PG::Connection.async_api = false) put_copy_data does a blocking flush every time new memory is allocated.
Unfortunately we don't have this kind of information, since we don't have access to libpq's PGconn struct and the return codes don't give us an indication when this happens.
So doing a flush at every fixed number of calls is a very simple heuristic.
Fixes#473
0 commit comments