Re: truncating casts of pgoff_t - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: truncating casts of pgoff_t
Date
Msg-id 8e1aee17-031e-44ef-93fb-a6bf0e180751@eisentraut.org
Whole thread
In response to Re: truncating casts of pgoff_t  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
On 22.06.26 10:55, Heikki Linnakangas wrote:
> Not that it makes much difference, but I'd suggest "if (histfilelen > 
> UINT32_MAX) elog(ERROR, ...)" here instead of an Assert. This isn't 
> performance critical and a better error message is always nice if 
> something weird happens. (I think on non-assertion builds, you'd get 
> "out of memory" error while trying to increase the send buffer).

Ok, committed with an elog instead.

> Not new with this patch, but I noticed that if the file increases in 
> size while we're reading it for some reason, we would read beyond the 
> originally calculated length. It really shouldn't happen, but it'd be 
> good to add an "nread <= bytesleft" check here, for the sake of robustness.

Yes, this is being addressed in the thread "clean up size_t/ssize_t use 
with POSIX file system APIs".




pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: injection_points: Switch wait/wakeup to use atomics rather than latches
Next
From: Hans Buschmann
Date:
Subject: Increased SECURITY RISCS from omitting some compikler options when building PG with meson; e.g. -fcf-protection=full