Re: truncating casts of pgoff_t

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: truncating casts of pgoff_t
Date: 2026-07-07 09:59:29
Message-ID: 8e1aee17-031e-44ef-93fb-a6bf0e180751@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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".

In response to

Browse pgsql-hackers by date

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