Re: [HACKERS] More thoughts about FE/BE protocol
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] More thoughts about FE/BE protocol |
Дата | |
Msg-id | 4809.1049992726@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | More thoughts about FE/BE protocol (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-interfaces |
Steve Crawford <scrawford@pinpointresearch.com> writes: > What would be the recovery/re-sync mechanism for those cases where the > message is, either accidentally or maliciously, longer or shorter than the > described length? Once you're out of sync, there's not much to do except abandon the connection. The detection mechanism for this would have two parts: (a) noticing an invalid message type code; (b) some kind of sanity check on the message length field. Also, if we insist that the internal layout of each message still permits detection of the end (eg, we still use null-terminated strings and so on), we could test for bytes being left over in the byte count. > Without proper timeout/recovery mechanisms a too-short message could cause > the receiver to effectively hang. I see no need to try to solve the Byzantine-generals problem here. A malicious attacker who's been able to connect to your database can do lots worse damage than just make the backend hang up. In the years I've been working with Postgres, I've never seen an out-of-sync problem that didn't arise directly from the lack-of-error- recovery deficiencies that this proposal addresses. I don't see any point in complicating the protocol still further to handle failures that don't arise in practice. regards, tom lane
В списке pgsql-interfaces по дате отправления: