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


> 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 →
  1. amcheck: Use correct varlena size accessor in bt_normalize_tuple()