Re: inserts into partitioned table may cause crash
От | Etsuro Fujita |
---|---|
Тема | Re: inserts into partitioned table may cause crash |
Дата | |
Msg-id | 5A97F4A1.5080209@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | inserts into partitioned table may cause crash (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: inserts into partitioned table may cause crash
|
Список | pgsql-hackers |
(2018/02/28 17:36), Amit Langote wrote: > I've run into what seems to be a bug in ExecInsert() that causes a crash > when inserting multiple rows into a partitioned table that each go into > different partitions with different tuple descriptors. Crash occurs if > ExecInsert() returns without resetting estate->es_result_relation_info > back to the root table's resultRelInfo. For example, if a BR trigger on a > partition returns NULL for a row. > > Crashing example: > > create table p (a int, b text) partition by list (a); > create table p12 (b text, a int); > > -- p12 has different tuple descriptor than p > alter table p attach partition p12 for values in (1, 2); > > create table p4 partition of p for values in (4); > > create function blackhole () returns trigger as $$ begin return NULL; end; > $$ language plpgsql; > create trigger blackhole before insert on p12 for each row execute > procedure blackhole(); > > insert into p values (1, 'b'), (4, 'a'); > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Failed. > > Crash is caused because we enter into ExecFindPartition with p12's > resultRelInfo as if it correponds to the root table. That happens because > we didn't reset estate->es_result_relation_info, which had been set to > p12's resultRelInfo to point back to the original resultRelInfo (that is, > p's) before returning like below: > > slot = ExecIRInsertTriggers(estate, resultRelInfo, slot); > > if (slot == NULL) /* "do nothing" */ > return NULL; > > There are other places where we prematurely return like that. > > Attached a patch to fix that, which would need to be back-patched to 10. Good catch! Will review. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: