Re: V3 protocol gets out of sync on messages that cause allocation failures

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: V3 protocol gets out of sync on messages that cause allocation failures
Date: 2004-10-18 17:04:00
Message-ID: 26685.1098119040@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Oliver Jowett <oliver(at)opencloud(dot)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();
normal read 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Wheeler 2004-10-18 17:06:29 Re: libpq and prepared statements progress for 8.0
Previous Message Bruce Momjian 2004-10-18 16:51:10 Re: [PATCHES] Open Items