BUG #16871: Insert with wrong key field, causing later crash of DB.
The following bug has been logged on the website:
Bug reference: 16871
Logged by: David Waddy
Email address: david@littleriver.ca
PostgreSQL version: 12.6
Operating system: linux
Description:
This has happened three times to me over the last few months. Database
crashes later on insert with faulty char[32] key field, matthew vs proper
key of matt.
PostgreSQL 12.6 (Ubuntu 12.6-0ubuntu0.20.04.1) on x86_64-pc-linux-gnu,
compiled by gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 64-bit
2021-02-16 10:58:13 AST STATEMENT: INSERT INTO
bovinemanagement.medicine_administered
(bovine_id,medicine_index,scheduled_event_time,dosage,dosage_unit,location,note,medical_case_id,scheduled_userid,calendar_event_id,protocol_uuid,uuid)
VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12)
2021-02-16 10:58:15 AST ERROR: invalid input syntax for type uuid: "2"
2021-02-16 10:58:15 AST STATEMENT: INSERT INTO
bovinemanagement.medicine_administered
(bovine_id,medicine_index,scheduled_event_time,dosage,dosage_unit,location,note,medical_case_id,scheduled_userid,calendar_event_id,protocol_uuid,uuid)
VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12)
2021-02-16 10:58:17 AST ERROR: invalid input syntax for type uuid: "2"
2021-02-16 10:58:17 AST STATEMENT: INSERT INTO
bovinemanagement.medicine_administered
(bovine_id,medicine_index,scheduled_event_time,dosage,dosage_unit,location,note,medical_case_id,scheduled_userid,calendar_event_id,protocol_uuid,uuid)
VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12)
2021-02-17 00:25:29 AST ERROR: insert or update on table "employee_shift"
violates foreign key constraint "employee_shift_userid_fkey"
2021-02-17 00:25:29 AST DETAIL: Key (userid)=(matthew
) is not present in table "users".
2021-02-17 00:25:29 AST STATEMENT: INSERT INTO batch.employee_shift
(userid, date, shift,milking_number) VALUES ('matthew', '2019-09-14',
'am',1);
2021-02-17 06:23:09 AST LOG: received fast shutdown request
2021-02-17 06:23:09 AST LOG: aborting any active transactions
2021-02-17 06:23:09 AST FATAL: terminating connection due to administrator
command
2021-02-17 06:23:09 AST FATAL: terminating connection due to administrator
command
2021-02-17 06:23:09 AST LOG: background worker "logical replication
launcher" (PID 4534) exited with exit code 1
2021-02-17 06:23:09 AST FATAL: terminating connection due to administrator
command
2021-02-17 06:23:09 AST LOG: shutting down
2021-02-17 06:23:10 AST LOG: database system is shut down
2021-02-17 07:09:29 AST LOG: starting PostgreSQL 12.6 (Ubuntu
12.6-0ubuntu0.20.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
9.3.0-17ubuntu1~20.04) 9.3.0, 64-bit
2021-02-17 07:09:29 AST LOG: listening on IPv4 address "0.0.0.0", port
5432
2021-02-17 07:09:29 AST LOG: listening on IPv6 address "::", port 5432
2021-02-17 07:09:29 AST LOG: listening on Unix socket
"/var/run/postgresql/.s.PGSQL.5432"
2021-02-17 07:09:29 AST LOG: database system was shut down at 2021-02-17
06:23:10 AST
2021-02-17 07:09:29 AST LOG: database system is ready to accept connections
PG Bug reporting form <noreply@postgresql.org> writes:
This has happened three times to me over the last few months. Database
crashes later on insert with faulty char[32] key field, matthew vs proper
key of matt.
2021-02-17 00:25:29 AST ERROR: insert or update on table "employee_shift"
violates foreign key constraint "employee_shift_userid_fkey"
2021-02-17 00:25:29 AST DETAIL: Key (userid)=(matthew
) is not present in table "users".
2021-02-17 00:25:29 AST STATEMENT: INSERT INTO batch.employee_shift
(userid, date, shift,milking_number) VALUES ('matthew', '2019-09-14',
'am',1);
2021-02-17 06:23:09 AST LOG: received fast shutdown request
2021-02-17 06:23:09 AST LOG: aborting any active transactions
Well, that's not a crash; that's a commanded shutdown. (The *only*
way to get that message is for something to send the postmaster a
SIGINT signal.) It's fairly hard to credit that there's any direct
connection to a simple SQL error six hours earlier, either.
I'm going to venture out on a limb here, but I'd suggest reviewing
exactly how you're starting Postgres. If you're launching it from
a manual shell command, and you're not being careful to fully dissociate
it from the shell's terminal, then you can get results like this when
you later type control-C, log out from that session, etc.
regards, tom lane