Re: inserts into partitioned table may cause crash

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: inserts into partitioned table may cause crash
Дата
Msg-id b7ee4acd-2816-37e6-1e53-cec0e06796d1@lab.ntt.co.jp
обсуждение исходный текст
Ответ на inserts into partitioned table may cause crash  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On 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.

BTW, this won't crash if the table descriptors match, but one would get an
unintuitive error like this:

create table p (a int, b text) partition by list (a);
create table p12 partition of p for values in (1, 2);
create table p4 partition of p for values in (4);
create trigger blackhole before insert on p12 for each row execute
procedure blackhole();

insert into p values (1, 'a'), (4, 'a');
ERROR:  new row for relation "p12" violates partition constraint
DETAIL:  Failing row contains (4, a).

That is, after trying to insert (4, 'a') into p12 as if it were the root.

Still, it's a bug all the same.

Thanks,
Amit



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Changing the autovacuum launcher scheduling; oldest table first algorithm
Следующее
От: Amit Langote
Дата:
Сообщение: Re: ON CONFLICT DO UPDATE for partitioned tables