Re: V3 protocol gets out of sync on messages that cause allocation failures
От | Tom Lane |
---|---|
Тема | Re: V3 protocol gets out of sync on messages that cause allocation failures |
Дата | |
Msg-id | 26685.1098119040@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | V3 protocol gets out of sync on messages that cause allocation failures (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: V3 protocol gets out of sync on messages that cause allocation failures
|
Список | pgsql-hackers |
Oliver Jowett <oliver@opencloud.com> writes: > What appears to be happening is that the backend goes into error > recovery as soon as the allocation fails (just after reading the message > length), and never does the read() of the body of the Bind message. So > it falls out of sync, and tries to interpret the guts of the Bind as a > new message. Bad server, no biscuit. Yeah. The intent of the protocol design was that the recipient could skip over the correct number of bytes even if it didn't have room to buffer them, but the memory allocation mechanism in the backend makes it difficult to actually do that. Now that we have PG_TRY, though, it might not be out of reach to do it right. Something like PG_TRY(); buf = palloc(N);PG_CATCH(); read and discard N bytes; re-raise the out-of-memory error;PG_END_TRY();normalread path I'm not sure how many places would need to be touched to make this actually happen; if memory serves, the "read a packet" code extends over multiple logical levels. regards, tom lane
В списке pgsql-hackers по дате отправления: