inserts into partitioned table may cause crash - Mailing list pgsql-hackers

From Amit Langote
Subject inserts into partitioned table may cause crash
Date
Msg-id 0473bf5c-57b1-f1f7-3d58-455c2230bc5f@lab.ntt.co.jp
Whole thread Raw
Responses Re: inserts into partitioned table may cause crash
Re: inserts into partitioned table may cause crash
List pgsql-hackers
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.

Thanks,
Amit

Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Incorrect comments in partition.c
Next
From: Masahiko Sawada
Date:
Subject: Changing the autovacuum launcher scheduling; oldest table first algorithm