| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: TRAP: failed Assert("offsets[i] > offsets[i - 1]"), File: "tidstore.c" |
| Date: | 2026-04-16 08:26:01 |
| Message-ID: | 119bd418-1d7a-42c7-9270-86f3b6696399@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 16/04/2026 10:11, Masahiko Sawada wrote:
> On Thu, Apr 16, 2026 at 12:13 AM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
> -- Random TIDs test. The offset numbers are randomized and must be --
> unique and ordered. INSERT INTO hideblocks (blockno) SELECT
> do_set_block_offsets(blkno, array_agg(DISTINCT greatest((random() *
> :maxoffset)::int, 1))::int2[]) FROM generate_series(1, 100)
> num_offsets, generate_series(1000, 1100, 1) blkno GROUP BY blkno;
Alright, I used an explicit sort in reverse order to make sure the test is
stable. I usually create modules that may change different paths, costs, and
orders, and using random can make things unpredictable. But for this specific
test, I don't see any risk.
>
> While I agree that we need to sort the offset numbers, I think it
> would be better to make sure the offset numbers in the array to be
> sorted in a test_tidstore.sql file where required, instead of doing so
> for all cases.
I'm not sure I follow. Are you saying that do_set_block_offsets shouldn't sort
the incoming offsets? I made this change mainly to meet the
TidStoreSetBlockOffsets contract. Since this is just a simple test, performance
isn't really a concern.
--
regards, Andrei Lepikhov,
pgEdge
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Borodin | 2026-04-16 12:00:14 | Re: BUG #19382: Server crash at __nss_database_lookup |
| Previous Message | Masahiko Sawada | 2026-04-16 08:11:47 | Re: TRAP: failed Assert("offsets[i] > offsets[i - 1]"), File: "tidstore.c" |