From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] dubious improvement in new psql |
Date: | 2000-01-12 19:38:20 |
Message-ID: | Pine.LNX.4.21.0001121346410.1646-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-01-12 19:38:29 | Re: [HACKERS] psql -f inconsistency with "copy from stdin" |
Previous Message | Hideyuki Kawashima | 2000-01-12 19:23:35 |