Message-ID: <ea7bd70e-212d-42ae-9677-72f2f5493f3c@gmail.com>
Date: Fri, 17 Apr 2026 23:26:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: TRAP: failed Assert("offsets[i] > offsets[i - 1]"), File:
 "tidstore.c"
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
References: <b97f1850-fc7b-43c4-9b04-4e97bb9e7dc0@gmail.com>
 <CAD21AoBVEcC5stzLr80RgaWuBh0EoyRQys_aeOz0ceogMVREcQ@mail.gmail.com>
 <cb7a4bad-007a-4bbe-8e4b-8ce8109c6e93@gmail.com>
 <CAD21AoC86nuoxy4r6G3_Ysb2y3K+0sybznRkjVq=Yc4URZUN4g@mail.gmail.com>
 <119bd418-1d7a-42c7-9270-86f3b6696399@gmail.com>
 <CAD21AoAit-Qp9OriVbb9c_Qebi=Cgxz0AQJu+zxQpp=_1Lt2dQ@mail.gmail.com>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: <CAD21AoAit-Qp9OriVbb9c_Qebi=Cgxz0AQJu+zxQpp=_1Lt2dQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/ea7bd70e-212d-42ae-9677-72f2f5493f3c%40gmail.com>
Precedence: bulk

On 16/04/2026 19:58, Masahiko Sawada wrote:
> On Thu, Apr 16, 2026 at 1:26 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
>>
>> 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?
> 
> No, I wanted to mean that if we sort the given array in
> do_set_block_offsets() as the proposed patch does, we end up always
> sorting arrays even if the sorting is no actually required (e.g., when
> executing "SELECT do_set_block_offsets(1,
> array[1,2,3,4,100]::int2[]);"). So an alternative idea to stabilize
> the regression test would be to create a SQL function to return a list
> of sorted offsets and use it where it's required. While the patch gets
> a little bigger, It would also help simplify the tests somewhat by
> removing the redundant codes. I've attached the patch for this idea.

Ok. No objections. Both changes are just test routines registered by the
test_tidstore module.

I decided to add C code, mostly following the idea that we reuse examples from
the Postgres codebase when writing our patches/extensions. An explicit
demonstration of the sort contract on the TidStoreSetBlockOffsets() call might
help developers who don't read function comments each time.

-- 
regards, Andrei Lepikhov,
pgEdge