Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server-side memory leak in PostgreSQL #19

Closed
b-s-a opened this issue Nov 19, 2012 · 6 comments
Closed

Server-side memory leak in PostgreSQL #19

b-s-a opened this issue Nov 19, 2012 · 6 comments
Assignees
Milestone

Comments

@b-s-a
Copy link
Contributor

b-s-a commented Nov 19, 2012

I try use SOCI in my project. But after some time I found, that SQL server (postgresql-8.4, 9.1, and 9.2) has eat all memory and killed by oom-killer. After some investigations I update library to recent master (today). But problem not fixed yet.

@mloskot
Copy link
Contributor

mloskot commented Nov 19, 2012

Can you confirm use are using prepared statements?
Recently, fix for prepared statement leak has been applied (see 02bb841b).

Unfortunately, the fix is causing regression. You can take a look at detailed explanation posted in the issue #13
I haven't had chance to come up with solution of this problem yet.

@b-s-a
Copy link
Contributor Author

b-s-a commented Nov 19, 2012

yes. I have use prepared statements (for rowset only).

@mloskot
Copy link
Contributor

mloskot commented Nov 19, 2012

And, can you confirm you have tried the source code with the fix for prepared statement leak applied. Namely, are you using SOCI with 02bb841b changes?

@b-s-a
Copy link
Contributor Author

b-s-a commented Nov 19, 2012

Yes. I confirm. I have use TODAY master. And I in real-time see (top), that postgres process eats 100KB per second (I do prepare every second).

@b-s-a
Copy link
Contributor Author

b-s-a commented Nov 27, 2012

I use prepare only in this construction:
{
soci::rowsetsoci::row res = (db.prepare << ....);
for(soci::rowsetsoci::row::iterator it = res.begin(), end = res.end(); it != end; ++it)
....
}

@b-s-a b-s-a mentioned this issue Nov 30, 2012
@ghost ghost assigned mloskot Dec 4, 2012
@mloskot
Copy link
Contributor

mloskot commented Dec 4, 2012

The fix has been merged into master SHA1: 8c05035
It also seems to solve the problem reported in the issue #13, great!
So, I'm going to partially revert the SHA1: 02bb841 fix, to avoid Premature deallocation of prepared statement. The SHA1: 8c05035 fix should be sufficient for that scenario too.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants