Re: [sqlsmith] Failed assertion during partition pruning - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [sqlsmith] Failed assertion during partition pruning
Date
Msg-id 919903.1606603948@sss.pgh.pa.us
Whole thread Raw
In response to [sqlsmith] Failed assertion during partition pruning  (Andreas Seltenreich <seltenreich@gmx.de>)
Responses Re: [sqlsmith] Failed assertion during partition pruning  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Andreas Seltenreich <seltenreich@gmx.de> writes:
> testing master at 3df51ca8 with sqlsmith triggers the following
> assertion:
>     TRAP: FailedAssertion("!bms_is_empty(present_parts)", File: "partprune.c", Line: 588, PID: 8540)

> I looked at a dozen backtraces and they all sport a window aggregate but
> that may still be random chance since sqlsmith really likes generating
> these a lot...

Yeah, it doesn't seem to need a window aggregate:

regression=# select a from trigger_parted where pg_trigger_depth() <> a order by a limit 40;
server closed the connection unexpectedly

What it looks like to me is that the code for setting up run-time
partition pruning has failed to consider the possibility of nested
partitioning: it's expecting that every partitioned table will have
at least one direct child that is a leaf.  I'm not sure though
whether just the Assert is wrong, or there's more fundamental
issues here.

It's also somewhat interesting that you need the "order by a limit 40"
to get a crash.  Poking around in the failing backend, I can see that
that causes the leaf-partition subplan to be an indexscan not a seqscan,
but it's far from clear why that'd make any difference to the partition
pruning logic.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andreas Seltenreich
Date:
Subject: [sqlsmith] Failed assertion during partition pruning
Next
From: Eugen Konkov
Date:
Subject: Feature Request: Report additionally error value