Re: inserts into partitioned table may cause crash

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: inserts into partitioned table may cause crash
Date: 2018-03-01 12:40:01
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2018-03-01 12:40:39 Re: Incorrect comments in partition.c
Previous Message Pavan Deolasee 2018-03-01 12:33:11 Re: [HACKERS] MERGE SQL Statement for PG11