Re: Assertion failure in smgr.c when using pg_prewarm with partitioned tables

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Assertion failure in smgr.c when using pg_prewarm with partitioned tables
Date: 2025-05-15 09:20:30
Message-ID: CAFiTN-tKxhMG0QNO1V3VNsfnhtkS=hrOJNj5Kxs6cGKtujdyhg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 15, 2025 at 2:22 PM Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com> wrote:
>
> Hi,
>
> I encountered an assertion failure when a partitioned table is specified
> as an argument to pg_prewarm. Below are the steps to reproduce the
> issue:
>
> $ pgbench -i -s 1 --partitions=3
> $ psql <<EOF
> CREATE EXTENSION pg_prewarm;
> SELECT pg_prewarm('pgbench_accounts');
> EOF
>
> The following assertion failure occurs:
>
> TRAP: failed Assert("RelFileNumberIsValid(rlocator.relNumber)"), File:
> "smgr.c", Line: 246, PID: 1246282
> postgres: ikeda postgres [local]
> SELECT(ExceptionalCondition+0xbb)[0x55edd16725c1]
> postgres: ikeda postgres [local] SELECT(smgropen+0x5e)[0x55edd145c1ff]
>
>
> It looks like this may have been overlooked in commit 049ef33.
> What do you think?

Yeah, this should be fixed, don't you think that instead of checking
the relnumber is valid, we shall check whether it's a partitioned rel
and give a separate error that prewarm is not supported for
partitioned tables? And in fact, we can think of supporting this for
the partitioned tables as well in the future, where we can loop
through all the partitions and do prewarm for each of them.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrei Lepikhov 2025-05-15 09:32:35 Re: Should we optimize the `ORDER BY random() LIMIT x` case?
Previous Message Aleksander Alekseev 2025-05-15 09:17:53 Re: Should we optimize the `ORDER BY random() LIMIT x` case?