{"push_id":2483065331,"size":1,"distinct_size":1,"ref":"refs/heads/REL9_5_STABLE","head":"2278e94ae9410716209487ad929d2eae24da0b47","before":"906e44d4dc83d551d26e52902435f18d9fa5cfc7","commits":[{"sha":"2278e94ae9410716209487ad929d2eae24da0b47","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"In libpq, free any partial query result before collecting a server error.\n\nWe'd throw away the partial result anyway after parsing the error message.\nThrowing it away beforehand costs nothing and reduces the risk of\nout-of-memory failure.  Also, at least in systems that behave like\nglibc/Linux, if the partial result was very large then the error PGresult\nwould get allocated at high heap addresses, preventing the heap storage\nused by the partial result from being released to the OS until the error\nPGresult is freed.\n\nIn psql >= 9.6, we hold onto the error PGresult until another error is\nreceived (for \\errverbose), so that this behavior causes a seeming\nmemory leak to persist for awhile, as in a recent complaint from\nDarafei Praliaskouski.  This is a potential performance regression from\nolder versions, justifying back-patching at least that far.  But similar\nbehavior may occur in other client applications, so it seems worth just\nback-patching to all supported branches.\n\nDiscussion: https://postgr.es/m/CAC8Q8tJ=7cOkPePyAbJE_Pf691t8nDFhJp0KZxHvnq_uicfyVg@mail.gmail.com","distinct":true,"url":"https://api.github.com/repos/postgres/postgres/commits/2278e94ae9410716209487ad929d2eae24da0b47"}]}
{"actor":{"display_login":"postgres-mirror"}}