Re: TRAP: failed Assert("offsets[i] > offsets[i - 1]"), File: "tidstore.c"
| От | Andrei Lepikhov |
|---|---|
| Тема | Re: TRAP: failed Assert("offsets[i] > offsets[i - 1]"), File: "tidstore.c" |
| Дата | |
| Msg-id | 119bd418-1d7a-42c7-9270-86f3b6696399@gmail.com обсуждение |
| Ответ на | Re: TRAP: failed Assert("offsets[i] > offsets[i - 1]"), File: "tidstore.c" (Masahiko Sawada <sawada.mshk@gmail.com>) |
| Ответы |
Re: TRAP: failed Assert("offsets[i] > offsets[i - 1]"), File: "tidstore.c"
|
| Список | pgsql-bugs |
On 16/04/2026 10:11, Masahiko Sawada wrote: > On Thu, Apr 16, 2026 at 12:13 AM Andrei Lepikhov <lepihov@gmail.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
В списке pgsql-bugs по дате отправления: