Re: Assertion being hit during WAL replay
| От | Tom Lane |
|---|---|
| Тема | Re: Assertion being hit during WAL replay |
| Дата | |
| Msg-id | 529161.1681246493@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Assertion being hit during WAL replay (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Assertion being hit during WAL replay
|
| Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes:
> On 2023-04-11 14:48:44 -0400, Tom Lane wrote:
>> I have seen this failure a couple of times recently while
>> testing code that caused crashes and restarts:
> Do you have a quick repro recipe?
Here's something related to what I hit that time:
diff --git a/src/backend/optimizer/plan/subselect.c b/src/backend/optimizer/plan/subselect.c
index 052263aea6..d43a7c7bcb 100644
--- a/src/backend/optimizer/plan/subselect.c
+++ b/src/backend/optimizer/plan/subselect.c
@@ -2188,6 +2188,7 @@ SS_charge_for_initplans(PlannerInfo *root, RelOptInfo *final_rel)
void
SS_attach_initplans(PlannerInfo *root, Plan *plan)
{
+ Assert(root->init_plans == NIL);
plan->initPlan = root->init_plans;
}
You won't get through initdb with this, but if you install this change
into a successfully init'd database and then "make installcheck-parallel",
it will crash and then fail to recover, at least a lot of the time.
regards, tom lane
В списке pgsql-hackers по дате отправления: