Re: [HACKERS] dubious improvement in new psql
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] dubious improvement in new psql |
Дата | |
Msg-id | Pine.LNX.4.21.0001121346410.1646-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | dubious improvement in new psql (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Okay, I looked at the code again and I can't see anything wrong conceptually. It follows libpq semantics which I remember to have grabbed from the documentation: results = PQexec(pset->db, query); /* do something with result */ if (PQstatus(pset->db) == CONNECTION_BAD){ fputs("The connection to the server was lost. Attempting reset: ", stderr); PQreset(pset->db); if (PQstatus(pset->db) == CONNECTION_BAD) { fputs("Failed.\n", stderr); PQfinish(pset->db); PQclear(results); pset->db = NULL; return false; } else fputs("Succeeded.\n",stderr);} If you can still reproduce this somehow, I'd like to know where it hangs and/or what the output was. On 1999-12-25, Tom Lane mentioned: > The new psql automatically tries to reconnect if the backend disconnects > unexpectedly. This feature strikes me as ill-conceived; furthermore > it appears to be buggy. > > It's ill-conceived because: > (1) under WAL, following a backend crash the postmaster is going to be > spending a few seconds reinitializing; an immediate reconnect attempt > is almost guaranteed to fail. Then rip out PQreset. It's not psql's job to make these kinds of decisions. > (2) if I'm running an SQL script, I think it's extremely foolhardy > to press on with executing the script as though nothing had happened. > A backend crash is not an event to be lightly ignored. Then rip out PQreset. To quote from the docs: "This function will close the connection to the backend and attempt to reestablish a new connection to the same postmaster, using all the same parameters previously used. This may be useful for error recovery if a working connection is lost." I don't know all the possible ways a backend can go down, but one of them might be a short network failure. In that case attempting a reset might be the reasonable thing to do. Again, this should be addressed at the libpq level. > > It's buggy because: it doesn't work reliably. While poking at the > backend's problems with oversize btree index entries, I saw psql claim > it had successfully reconnected, and then go into a catatonic state. Look at the above code; seems like a libpq problem. > It wouldn't give me a new command prompt (not even with ^C), wouldn't > exit with ^D, and had to be killed from another shell window. > > This behavior doesn't seem to happen for every crash, but I'm not > really interested in trying to debug it. I think the "feature" I am. :) > ought to be ripped out. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: