libpq and connection failures
От | jtv@xs4all.nl |
---|---|
Тема | libpq and connection failures |
Дата | |
Msg-id | 21028.202.47.227.25.1120571298.squirrel@202.47.227.25 обсуждение исходный текст |
Ответы |
Re: libpq and connection failures
|
Список | pgsql-interfaces |
Is there any reason why pqReadData() (interfaces/libpq/fe-misc.c), if pqsecure_read() fails with an error that isn't special-cased as a transient one, returns -1 but leaves the connection state at CONNECTION_OK? Was this meant to be caught by calling pqReadReady() (which doesn't happen in this case because of the return)? Some libpqxx users with postgres 8.0 installed have observed broken backend connections leading to errors but not updating connection state accordingly. One user unplugged his network cable, leading to a long timeout followed by the error message "could not receive data from server," but libpqxx was unable to diagnose the situation because PQstatus() blithely returned CONNECTION_OK. Doesn't it make more sense in these cases to "goto definitelyFailed" instead of "return -1" as it does now? This occurs in two places BTW, so it may make sense to refactor the function before changing it: the code blocks at labels retry3 and retry4 are completely identical AFAICS except for one small "if" clause (plus a variable is replaced by 0 where it's provably equal to zero). Each is really a switch within a loop, disguised as a nested if through cunning use of goto. Jeroen
В списке pgsql-interfaces по дате отправления: