Re: libpqrcv_connect() leaks PGconn
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Noah Misch <noah@leadboat.com>
Cc: pgsql-hackers@postgresql.org
Date: 2023-01-24T02:58:17Z
Lists: pgsql-hackers
On 2023-01-21 23:14:08 -0800, Noah Misch wrote: > On Sat, Jan 21, 2023 at 12:04:53PM -0800, Andres Freund wrote: > > On 2023-01-21 08:16:42 -0800, Noah Misch wrote: > > > On Fri, Jan 20, 2023 at 06:50:37PM -0800, Andres Freund wrote: > > > > I seems we don't have any tests for creating a subscription that fails during > > > > connection establishment? That doesn't seem optimal - I guess there may have > > > > been concern around portability of the error messages? > > > > > > Perhaps. We have various (non-subscription) tests using "\set VERBOSITY > > > sqlstate" for that problem. If even the sqlstate varies, a DO block is the > > > next level of error swallowing. > > > > That's a good trick I need to remember. And the errcode for an invalid > > connection string luckily differs from the one for a not working one. > > > > > > I think found an even easier way - port=-1 is rejected during PQconnectPoll() > > and will never even open a socket. That'd make it reasonable for the test to > > happen in subscription.sql, instead of a tap test, I think (faster, easier to > > maintain). It may be that we'll one day move that error into the > > PQconninfoParse() phase, but I don't think we need to worry about it now. > > > > Any reason not to go for that? > > No, a port=-1 test in subscription.sql sounds ideal. Cool. Thanks for the review - pushed that way.
Commits
-
Fix error handling in libpqrcv_connect()
- 243373159fb4 11.19 landed
- 92fc1278786f 12.14 landed
- c5864805ba99 13.10 landed
- 0a796b8b3e31 14.7 landed
- 704a330a9ee8 15.2 landed
- bc54ef4ec25a 16.0 landed