Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum
Andrey Borodin <x4mmm@yandex-team.ru>
From: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
To: Michael Zhilin <m.zhilin@postgrespro.ru>
Cc: pgsql-bugs@postgresql.org,
y sokolov <y.sokolov@postgrespro.ru>,
Alexander Lakhin <exclusion@gmail.com>
Date: 2024-01-07T18:04:35Z
Lists: pgsql-bugs
Attachments
- v1rebased-0001-contrib-amcheck-must-support-different-hea.patch (application/octet-stream) patch 0001
- (unnamed) (text/plain)
> On 14 Dec 2023, at 21:18, Michael Zhilin <m.zhilin@postgrespro.ru> wrote: I've checked that: * bug is reproduced by the test in the patch * bug is fixed by the patch * fix seems idiomatic, similar to nearby code Patch needed a rebase, so please find attached rebased version. I did not change anything. I see that using a temp file in PG_ABS_SRCDIR is common approach. But still I want to ask, maybe can we develop some clever way to reproduce the bug without external file? Also, maybe nearby code would be slightly more readable, if normalized[i] was a local variable. And one last question about the line: char *data = palloc(len); what if data is somehow corrupted here... are there enough sanity checks that we won't palloc(-1) or something like that? Won't we memcpy() from some other memory when len is bogus? Besides this paranoid questions, I think that this patch is ready for committer. Thanks! Best regards, Andrey Borodin.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
amcheck: Use correct varlena size accessor in bt_normalize_tuple()
- 4284476c0f67 15 (unreleased) landed
- c89a1ca01344 16 (unreleased) landed
- 8abb8a1555f4 17 (unreleased) landed
- af09b18cbadb 14 (unreleased) landed
- 897e79486296 18 (unreleased) landed
- da1eff08a5be 19 (unreleased) landed