Hi, On Wednesday, September 05, 2012 06:00:18 PM Tom Lane wrote: > "anara...@anarazel.de" <and...@anarazel.de> writes: > > I am not saying its bad that it is slower, that's absolutely OK. Just > > that it will take a variable amount of time till you can run pgdump > > again and its not easily detectable without looping and trying again. > > Well, that's why the proposed libpq code is written to wait for the > child postgres to exit when closing the connection. > > Admittedly, if you forcibly kill pg_dump (or some other client) and then > immediately try to start a new one, it's not clear how long you'll have > to wait. Yep, thats the case I was talking about upthread ;)
On Monday, September 03, 2012 11:04:15 PM Andres Freund wrote: > Don't we expect some more diligence in applications using this against > letting such a child continue to run after ctrl-c/SIGTERMing e.g. pg_dump > in comparison to closing a normal database connection? I would really expect any postgres supplied core tool to try to handle that case. Thats not exactly trivial to do right and requires cooperation of the application. Because that requires knowledge about the operation mode in those anyway I don't really see an extra libpq call as problematic... > But so what? Anything we might do in this space is going to > have pluses and minuses. True. Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
