Обсуждение: BUG #16087: Segmentation fault on ALTER TABLE

Поиск
Список
Период
Сортировка

BUG #16087: Segmentation fault on ALTER TABLE

От
PG Bug reporting form
Дата:
The following bug has been logged on the website:

Bug reference:      16087
Logged by:          Ariel Mashraki
Email address:      ariel@mashraki.co.il
PostgreSQL version: 12.0
Operating system:   Docker (Debian 12.0-2.pgdg100+1) on OSX
Description:

Running ALTER TABLE with both ALTER COLUMN and ADD COLUMN causes a database
segfault. It happens constantly on version 12 and doesn't reproduce on
version 11 and 10.
Attaching here a set of commands (and their output) to help reproducing the
issue ($ means start of a command).

$ create table "users" (id bigint not null generated by default as identity,
age int not null, primary key(id));
$ insert into users (age) values(1);
$ alter table "users" alter column "age" type bigint, add column "nickname"
text;

Command output:
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.


Database logs:
2019-10-29 15:08:25.143 UTC [1] LOG:  server process (PID 1747) was
terminated by signal 11: Segmentation fault
2019-10-29 15:08:25.143 UTC [1] DETAIL:  Failed process was running: alter
table "users" alter column "age" type bigint, add column "nickname" text;
2019-10-29 15:08:25.143 UTC [1] LOG:  terminating any other active server
processes
2019-10-29 15:08:25.144 UTC [1725] WARNING:  terminating connection because
of crash of another server process
2019-10-29 15:08:25.144 UTC [1725] DETAIL:  The postmaster has commanded
this server process to roll back the current transaction and exit, because
another server process exited abnormally and possibly corrupted shared
memory.
2019-10-29 15:08:25.144 UTC [1725] HINT:  In a moment you should be able to
reconnect to the database and repeat your command.
2019-10-29 15:08:25.146 UTC [1903] FATAL:  the database system is in
recovery mode
2019-10-29 15:08:25.148 UTC [1] LOG:  all server processes terminated;
reinitializing
2019-10-29 15:08:25.167 UTC [1904] LOG:  database system was interrupted;
last known up at 2019-10-29 14:58:57 UTC
2019-10-29 15:08:25.320 UTC [1904] LOG:  database system was not properly
shut down; automatic recovery in progress
2019-10-29 15:08:25.329 UTC [1904] LOG:  redo starts at 0/19835A8
2019-10-29 15:08:25.330 UTC [1904] LOG:  invalid record length at 0/199D778:
wanted 24, got 0
2019-10-29 15:08:25.330 UTC [1904] LOG:  redo done at 0/199D740
2019-10-29 15:08:25.354 UTC [1] LOG:  database system is ready to accept
connections


Re: BUG #16087: Segmentation fault on ALTER TABLE

От
Tom Lane
Дата:
PG Bug reporting form <noreply@postgresql.org> writes:
> Running ALTER TABLE with both ALTER COLUMN and ADD COLUMN causes a database
> segfault. It happens constantly on version 12 and doesn't reproduce on
> version 11 and 10.
> Attaching here a set of commands (and their output) to help reproducing the
> issue ($ means start of a command).

> $ create table "users" (id bigint not null generated by default as identity,
> age int not null, primary key(id));
> $ insert into users (age) values(1);
> $ alter table "users" alter column "age" type bigint, add column "nickname"
> text;

Thanks for the report!  I failed to reproduce a crash here, but I think
that means that the bug is already fixed.  It looks like this probably
matches this recent commit:

Author: Andres Freund <andres@anarazel.de>
Branch: master [93765bd95] 2019-10-09 22:00:50 -0700
Branch: REL_12_STABLE [f224c7c11] 2019-10-09 22:13:48 -0700

    Fix table rewrites that include a column without a default.
    
    In c2fe139c201c I made ATRewriteTable() use tuple slots. Unfortunately
    I did not notice that columns can be added in a rewrite that do not
    have a default, when another column is added/altered requiring one.
    
    Initialize columns to NULL again, and add tests.
    
    Bug: #16038
    Reported-By: anonymous
    Author: Andres Freund
    Discussion: https://postgr.es/m/16038-5c974541f2bf6749@postgresql.org
    Backpatch: 12, where the bug was introduced in c2fe139c201c

            regards, tom lane