Re: BUG #15684: Server crash on DROP partitioned table

The following bug has been logged on the website:

Bug reference: 15684
Logged by: Alexander Lakhin
Email address: exclusion(at)gmail(dot)com
PostgreSQL version: 11.2
Operating system: Ubuntu 18.04
Description:

The following query:
create table at_partitioned (a int, b text) partition by range (a);
create table at_part_1 partition of at_partitioned for values from (0) to
(1000);
create table at_part_2 partition of at_partitioned for values from (1000) to
(2000);
create index on at_partitioned (b);
alter table at_partitioned alter column b type numeric using b::numeric;
alter table at_partitioned alter column b type numeric using b::numeric;
drop table at_partitioned cascade;

crashes server (on REL_11_2 and REL_11_STABLE) with the error messages:
psql:query.sql:7: WARNING: AbortTransaction while in COMMIT state
psql:query.sql:7: ERROR: SMgrRelation hashtable corrupted
PANIC: cannot abort transaction 575, it was already committed
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
psql:query.sql:7: connection to server was lost

and the following stack trace:
Core was generated by `postgres: law regression [local] DROP TABLE
'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig(at)entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f715f347801 in __GI_abort () at abort.c:79
#2 0x00005624ec109351 in errfinish (dummy=dummy(at)entry=0) at elog.c:555
#3 0x00005624ec10b1c6 in elog_finish (elevel=elevel(at)entry=22,
fmt=fmt(at)entry=0x5624ec195190 "cannot abort transaction %u, it was
already committed") at elog.c:1376
#4 0x00005624ebd63826 in RecordTransactionAbort
(isSubXact=isSubXact(at)entry=false) at xact.c:1580
#5 0x00005624ebd63942 in AbortTransaction () at xact.c:2602
#6 0x00005624ebd64385 in AbortCurrentTransaction () at xact.c:3144
#7 0x00005624ebfeba10 in PostgresMain (argc=<optimized out>,
argv=argv(at)entry=0x5624ece2d748, dbname=<optimized out>,
username=0x5624ecdfeab8 "law") at postgres.c:3968
#8 0x00005624ebcc133d in BackendRun (port=0x5624ece25e40) at
postmaster.c:4361
#9 BackendStartup (port=0x5624ece25e40) at postmaster.c:4033
#10 ServerLoop () at postmaster.c:1706
#11 0x00005624ebf6a668 in PostmasterMain (argc=3, argv=0x5624ecdfc9f0) at
postmaster.c:1379
#12 0x00005624ebcc2f69 in main (argc=3, argv=0x5624ecdfc9f0) at main.c:228

Hi,

On Sun, Mar 10, 2019 at 7:55 PM PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
>
> The following query:
> create table at_partitioned (a int, b text) partition by range (a);
> create table at_part_1 partition of at_partitioned for values from (0) to
> (1000);
> create table at_part_2 partition of at_partitioned for values from (1000) to
> (2000);
> create index on at_partitioned (b);
> alter table at_partitioned alter column b type numeric using b::numeric;
> alter table at_partitioned alter column b type numeric using b::numeric;
> drop table at_partitioned cascade;
>
> crashes server (on REL_11_2 and REL_11_STABLE) with the error messages:
> psql:query.sql:7: WARNING: AbortTransaction while in COMMIT state
> psql:query.sql:7: ERROR: SMgrRelation hashtable corrupted
> PANIC: cannot abort transaction 575, it was already committed
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> psql:query.sql:7: connection to server was lost
>
> and the following stack trace:
> [...]

It seems to be the same bug as described in bug #15672
(/message-id/15672-b9fa7db32698269f@postgresql.org)
I'm Cc-ing Amit just in case.

Hello Julien,
10.03.2019 22:04, Julien Rouhaud wrote:
> Hi,
>
> On Sun, Mar 10, 2019 at 7:55 PM PG Bug reporting form
> <noreply(at)postgresql(dot)org> wrote:
>> The following query:
>> create table at_partitioned (a int, b text) partition by range (a);
>> create table at_part_1 partition of at_partitioned for values from (0) to
>> (1000);
>> create table at_part_2 partition of at_partitioned for values from (1000) to
>> (2000);
>> create index on at_partitioned (b);
>> alter table at_partitioned alter column b type numeric using b::numeric;
>> alter table at_partitioned alter column b type numeric using b::numeric;
>> drop table at_partitioned cascade;
>>
> It seems to be the same bug as described in bug #15672
> (/message-id/15672-b9fa7db32698269f@postgresql.org)
> I'm Cc-ing Amit just in case.
Yes, after applying the patch presented in that thread the crash is not
reproduced.
Thanks for the tip!

Best regards,
Alexander

On 2019/03/11 4:15, Alexander Lakhin wrote:
> 10.03.2019 22:04, Julien Rouhaud wrote:
>> Hi,
>>
>> On Sun, Mar 10, 2019 at 7:55 PM PG Bug reporting form
>> <noreply(at)postgresql(dot)org> wrote:
>>> The following query:
>>> create table at_partitioned (a int, b text) partition by range (a);
>>> create table at_part_1 partition of at_partitioned for values from (0) to
>>> (1000);
>>> create table at_part_2 partition of at_partitioned for values from (1000) to
>>> (2000);
>>> create index on at_partitioned (b);
>>> alter table at_partitioned alter column b type numeric using b::numeric;
>>> alter table at_partitioned alter column b type numeric using b::numeric;
>>> drop table at_partitioned cascade;
>>>
>> It seems to be the same bug as described in bug #15672
>> (/message-id/15672-b9fa7db32698269f@postgresql.org)
>> I'm Cc-ing Amit just in case.

Thanks Julien.

To summarize, the problem is that partition/child indexes, when recreated
due to ALTER COLUMN, all get the same relfilenode, which amounts to a
corrupted catalog state.

> Yes, after applying the patch presented in that thread the crash is not
> reproduced.
> Thanks for the tip!

Unfortunately, the patch I posted there is still very sketchy. I will try
to revise it this week and will be waiting for comments.

Thanks,
Amit