From: | Matthias van de Meent <boekewurm(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Subject: | PG17beta2: SMGR: inconsistent type for nblocks |
Date: | 2024-07-30 11:24:04 |
Message-ID: | CAEze2WjZLur_=VSbjZ_tVJdWkRqt9Kbzj1+GJena82KGYDFqAw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
While working on rebasing the patches of Neon's fork onto the
REL_17_STABLE branch, I noticed that the nblocks arguments of various
smgr functions have inconsistent types: smgrzeroextend accepts
`nblocks` as signed integer, as does the new signature for
smgrprefetch, but the new vectorized operations of *readv and *writev,
and the older *writeback all use an unsigned BlockNumber as indicator
for number of blocks.
Can we update the definition to be consistent across this (new, or
also older) API? As far as I can see, in none of these cases are
negative numbers allowed or expected, so updating this all to be
consistently BlockNumber across the API seems like a straigthforward
patch.
cc-ed Thomas as committer of the PG17 smgr API changes.
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
From | Date | Subject | |
---|---|---|---|
Next Message | shveta malik | 2024-07-30 11:26:21 | Re: Conflict Detection and Resolution |
Previous Message | Heikki Linnakangas | 2024-07-30 11:22:19 | Minor refactorings to eliminate some static buffers |