Обсуждение: pgsql: Code cleanup for toast_fetch_datum and toast_fetch_datum_slice.
Code cleanup for toast_fetch_datum and toast_fetch_datum_slice. Rework some of the checks for bad TOAST chunks to be a bit simpler and easier to understand. These checks verify that (1) we get all and only the chunk numbers we expect to see and (2) each chunk has the expected size. However, the existing code was a bit hard to understand, at least for me; try to make it clearer. As part of that, have toast_fetch_datum_slice check the relationship between endchunk and totalchunks only with an Assert() rather than checking every chunk number against both values. There's no need to check that relationship in production builds because it's not a function of whether on-disk corruption is present; it's just a question of whether the code does the right math. Also, have toast_fetch_datum_slice() use ereport(ERROR) rather than elog(ERROR). Commit fd6ec93bf890314ac694dc8a7f3c45702ecc1bbd made the two functions inconsistent with each other. Rename assorted variables for better clarity and consistency, and move assorted variables from function scope to the function's main loop. Remove a few variables that are used only once entirely. Patch by me, reviewed by Peter Eisentraut. Discussion: http://postgr.es/m/CA+TgmobBzxwFojJ0zV0Own3dr09y43hp+OzU2VW+nos4PMXWEg@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/d5406dea25b600408e7acf17d5a06e82d3ce6d0d Modified Files -------------- src/backend/access/common/detoast.c | 220 +++++++++++++++++------------------- 1 file changed, 102 insertions(+), 118 deletions(-)
On Tue, Dec 17, 2019 at 2:52 PM Robert Haas <rhaas@postgresql.org> wrote: > Code cleanup for toast_fetch_datum and toast_fetch_datum_slice. florican seems unhappy with this. Looking at it now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Dec 17, 2019 at 2:52 PM Robert Haas <rhaas@postgresql.org> wrote:
>> Code cleanup for toast_fetch_datum and toast_fetch_datum_slice.
> florican seems unhappy with this. Looking at it now.
lapwing as well; maybe some 64-bit-ish assumptions in there?
regards, tom lane
On Tue, Dec 17, 2019 at 3:54 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Tue, Dec 17, 2019 at 2:52 PM Robert Haas <rhaas@postgresql.org> wrote: > >> Code cleanup for toast_fetch_datum and toast_fetch_datum_slice. > > > florican seems unhappy with this. Looking at it now. > > lapwing as well; maybe some 64-bit-ish assumptions in there? It actually seems to be due to the fact that the 32-bit machine has a different TOAST chunk size (2000) than the 64-bit machine (1996). There is no test which uses an amount of data that is a multiple of the latter value, but there was a test which used data that is a multiple of the former value, so it worked OK for me locally, but failed (mostly by luck) with the different TOAST size. Possibly we should add some more tests here... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company