Re: Flushing large data immediately in pqcomm

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Subject: Re: Flushing large data immediately in pqcomm
Date: 2024-04-07 10:04:48
Message-ID: CAGECzQQUNpu2NQB01FLEVnxPeYBY1V5eG24z11BTMz9R6J5nyQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 7 Apr 2024 at 03:39, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Changing the global vars to size_t seems mildly bogus to me. All it's
> achieving is to use slightly more memory. It also just seems unrelated to the
> change.

I took a closer look at this. I agree that changing PqSendBufferSize
to size_t is unnecessary: given the locations that it is used I see no
risk of overflow anywhere. Changing the type of PqSendPointer and
PqSendStart is needed though, because (as described by Heiki and David
upthread) the argument type of internal_flush_buffer is size_t*. So if
you actually pass int* there, and the sizes are not the same then you
will start writing out of bounds. And because internal_flush_buffer is
introduced in this patch, it is related to this change.

This is what David just committed too.

However, the "required" var actually should be of size_t to avoid
overflow if len is larger than int even without this change. So
attached is a tiny patch that does that.

Attachment Content-Type Size
v7-0001-Avoid-possible-overflow-in-socket_putmessage_nonb.patch application/octet-stream 1009 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2024-04-07 10:05:36 Re: Add bump memory context type and use it for tuplesorts
Previous Message John Naylor 2024-04-07 09:44:56 Re: [PoC] Improve dead tuple storage for lazy vacuum