From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: amcheck (B-Tree integrity checking tool) |
Date: | 2016-03-11 21:15:43 |
Message-ID: | CAM3SWZROTT-Hxm3Qh_4DpNQG_=S=tCVnQPgkEOzU0uNOMjE0Ug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 11, 2016 at 1:09 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> Or, you could add code like this to comparetup_index_btree(), to
> simulate a broken opclass:
>
> diff --git a/src/backend/utils/sort/tuplesort.c
> b/src/backend/utils/sort/tuplesort.c
> index 67d86ed..23712ff 100644
> --- a/src/backend/utils/sort/tuplesort.c
> +++ b/src/backend/utils/sort/tuplesort.c
> @@ -3562,6 +3562,9 @@ comparetup_index_btree(const SortTuple *a, const
> SortTuple *b,
> compare = ApplySortComparator(a->datum1, a->isnull1,
>
> b->datum1, b->isnull1,
> sortKey);
> +
> + if (random() <= (MAX_RANDOM_VALUE / 1000))
> + compare = -compare;
> if (compare != 0)
> return compare;
Note that this patch that I sketched would make CREATE INDEX produce
corrupt indexes, but the tool's verification itself would not be
affected. Although even if it was (even if _bt_compare() gave the same
wrong answers), it would still very likely detect corruption.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-03-11 21:22:34 | Re: Background Processes and reporting |
Previous Message | Peter Geoghegan | 2016-03-11 21:09:44 | Re: amcheck (B-Tree integrity checking tool) |