Re: [sqlsmith] Failed assertion during partition pruning
От | Tom Lane |
---|---|
Тема | Re: [sqlsmith] Failed assertion during partition pruning |
Дата | |
Msg-id | 919903.1606603948@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [sqlsmith] Failed assertion during partition pruning (Andreas Seltenreich <seltenreich@gmx.de>) |
Ответы |
Re: [sqlsmith] Failed assertion during partition pruning
|
Список | 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 по дате отправления: