From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andreas Seltenreich <seltenreich(at)gmx(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [sqlsmith] Failed assertion during partition pruning |
Date: | 2020-11-28 22:52:28 |
Message-ID: | 919903.1606603948@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andreas Seltenreich <seltenreich(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Eugen Konkov | 2020-11-28 22:57:58 | Feature Request: Report additionally error value |
Previous Message | Andreas Seltenreich | 2020-11-28 21:43:06 | [sqlsmith] Failed assertion during partition pruning |