PostgreSQL 17.2 servers crashing due to segmentation faults on query execution
Hi,
We are encountering crashes on our PostgreSQL 17.2 servers (both on Windows and Linux) while executing certain queries from one of our applications. On Windows, the error code we are receiving is 0xC0000005, and on Linux, the syslog entry is as follows:
Jan 24 10:33:43 PG-Calidad kernel: [4918324.637184] postgres[3776969]: segfault at efe545 ip 0000557658bb3347 sp 00007fffd5cb8f68 error 4 in postgres[557658698000+569000]
Jan 24 10:33:43 PG-Calidad kernel: [4918324.637201] Code: 25 28 00 00 00 75 16 48 83 c4 48 5d 41 5c c3 0f 1f 40 00 48 89 c7 e8 e8 b5 b7 ff eb da e8 11 70 ae ff 90 f3 0f 1e fa 48 89 f8 <f6> 07 03 75 04 c3 0f 1f 00 e9 cb b5 b7 ff 66 66 2e 0f 1f 84 00 00
We have created a minimal reproducible example (with a full backup and data attached), and it appears the issue is related to unions of columns with different, but auto-coercible, types such as bigint and numeric(19,0).
create table t1 (
id int primary key,
code int
);
create table t2 (
id bigint primary key,
date timestamp,
t1_id int references t1(id)
);
create index t2_idx on t2(t1_id, date);
select t1.code, t2a.id as tid
from t2 t2b
inner join t2 t2a on t2b.id = t2a.id
inner join t1 on t2a.t1_id = t1.id
where t2a.t1_id = 280686 and t2a.date >= '2025-01-01'
group by t1.id, t1.code, t2a.id
union
(select 0, cast(0 as numeric(19,0)));
The execution plan for this query is as follows:
Unique (cost=1515.74..1516.84 rows=146 width=36)
-> Sort (cost=1515.74..1516.11 rows=146 width=36)
Sort Key: "*SELECT* 1".code, (("*SELECT* 1".tid)::numeric)
-> Append (cost=1507.58..1510.49 rows=146 width=36)
-> Subquery Scan on "*SELECT* 1" (cost=1507.58..1509.75 rows=145 width=36)
-> Sort (cost=1507.58..1507.94 rows=145 width=16)
Sort Key: t1.code, t2a.id USING <
-> Group (cost=1501.65..1502.37 rows=145 width=16)
Group Key: t2a.id
-> Sort (cost=1501.65..1502.01 rows=145 width=16)
Sort Key: t2a.id
-> Nested Loop (cost=6.33..1496.44 rows=145 width=16)
-> Seq Scan on t1 (cost=0.00..3.35 rows=1 width=8)
Filter: (id = 280686)
-> Nested Loop (cost=6.33..1491.64 rows=145 width=12)
-> Bitmap Heap Scan on t2 t2a (cost=5.91..396.21 rows=145 width=12)
Recheck Cond: ((t1_id = 280686) AND (date >= '2025-01-01 00:00:00'::timestamp without time zone))
-> Bitmap Index Scan on t2_idx (cost=0.00..5.87 rows=145 width=0)
Index Cond: ((t1_id = 280686) AND (date >= '2025-01-01 00:00:00'::timestamp without time zone))
-> Index Only Scan using t2_pkey on t2 t2b (cost=0.42..7.55 rows=1 width=8)
Index Cond: (id = t2a.id)
-> Result (cost=0.00..0.01 rows=1 width=24)
The issue seems to occur when executing plans with the Sort operation (indicated in bold) and the "USING <" annotation.
We hope this information helps to pinpoint and resolve the issue.
Thank you for your attention to this matter, and for your continued work on improving PostgreSQL.
Best regards,
[https://avaloninformatica.com/email-signature/Avalon.gif]<https://www.avaloninformatica.com/>
Víctor Castro
CTO
Desarrollo
[https://avaloninformatica.com/email-signature/phone-icon.png] +34 916 347 750<tel:+34916347750>
[https://avaloninformatica.com/email-signature/email-icon.png] vcastro@avaloninformatica.com<mailto:info@avaloninformatica.com>
[https://avaloninformatica.com/email-signature/link-icon.png] www.avaloninformatica.com<https://avaloninformatica.com/>
[https://avaloninformatica.com/email-signature/linkedin.png] LinkedIN<https://www.linkedin.com/company/avalon-informatica-y-servicios-slu/>
[https://avaloninformatica.com/email-signature/address-icon.png] P. Empresarial El Carralero, 4. 28222 Majadahonda. Madrid (SPAIN)<https://goo.gl/maps/Z8bPMxE1q5PJ9Tvk8>
DATA PROTECTION: In compliance with the GDPR (EU) 2016/679 and LOPDGDD 3/2018 we inform you that your data will be processed by the Controller: AVALON INFORMATICA Y SERVICIOS, S.L.U. with the purpose of sending information, answer your questions or queries and maintenance of the existing relationship. Legal basis: the performance of a contract to which the data subject is party, the compliance with a legal obligation to which the controller is subject, or your consent which can be withdrawn anytime. Period for which personal data will be stored: as long as necessary for the purpose described and the interested party does not oppose. Recipients: No data will be transferred to third parties, except legal obligation. Rights: You can exercise your rights to access, oppose, limit the treatment, amend, cancel or exercise the right to the portability by writing, together with a copy of the official document that identifies you to the Controller at the following address: RONDA EL CARRALERO 4, MAJADAHONDA (28222) MADRID, SPAIN or by email: info@avaloninformatica.com. You can also oppose our advertising communications (Art. 21.2 LSSI) at the same address. In case of disagreement you also have the right to submit a complaint to the Spanish Supervisory Authority (www.aepd.es).
Attachments:
dump-test-202501271525.zipapplication/x-zip-compressed; name=dump-test-202501271525.zipDownload+5-11
On Mon, 2025-01-27 at 14:55 +0000, Victor Castro Amigo wrote:
We are encountering crashes on our PostgreSQL 17.2 servers (both on Windows and Linux)
while executing certain queries from one of our applications.We have created a minimal reproducible example (with a full backup and data attached),
and it appears the issue is related to unions of columns with different, but auto-coercible,
types such asbigint and numeric(19,0).create table t1 (
id int primary key,
code int
);create table t2 (
id bigint primary key,
date timestamp,
t1_id int references t1(id)
);create index t2_idx on t2(t1_id, date);
select t1.code, t2a.id as tid
from t2 t2b
inner join t2 t2a on t2b.id = t2a.id
inner join t1 on t2a.t1_id = t1.id
where t2a.t1_id = 280686 and t2a.date >= '2025-01-01'
group by t1.id, t1.code, t2a.id
union
(select 0, cast(0 as numeric(19,0)));The execution plan for this query is as follows:
Unique (cost=1515.74..1516.84 rows=146 width=36)
-> Sort (cost=1515.74..1516.11 rows=146 width=36)
Sort Key: "*SELECT* 1".code, (("*SELECT* 1".tid)::numeric)
-> Append (cost=1507.58..1510.49 rows=146 width=36)
-> Subquery Scan on "*SELECT* 1" (cost=1507.58..1509.75 rows=145 width=36)
-> Sort (cost=1507.58..1507.94 rows=145 width=16)
Sort Key: t1.code, t2a.id USING <
-> Group (cost=1501.65..1502.37 rows=145 width=16)
Group Key: t2a.id
-> Sort (cost=1501.65..1502.01 rows=145 width=16)
Sort Key: t2a.id
-> Nested Loop (cost=6.33..1496.44 rows=145 width=16)
-> Seq Scan on t1 (cost=0.00..3.35 rows=1 width=8)
Filter: (id = 280686)
-> Nested Loop (cost=6.33..1491.64 rows=145 width=12)
-> Bitmap Heap Scan on t2 t2a (cost=5.91..396.21 rows=145 width=12)
Recheck Cond: ((t1_id = 280686) AND (date >= '2025-01-01 00:00:00'::timestamp without time zone))
-> Bitmap Index Scan on t2_idx (cost=0.00..5.87 rows=145 width=0)
Index Cond: ((t1_id = 280686) AND (date >= '2025-01-01 00:00:00'::timestamp without time zone))
-> Index Only Scan using t2_pkey on t2 t2b (cost=0.42..7.55 rows=1 width=8)
Index Cond: (id = t2a.id)
-> Result (cost=0.00..0.01 rows=1 width=24)The issue seems to occur when executing plans with the Sort operation (indicated in bold) and the"USING <" annotation.
This seems to be the same problem as bug 18764:
/messages/by-id/18764-63ad667ea26e877a@postgresql.org
Strangely enough, your test case does not fail on my 17.2.
17.3 will contain a fix.
Yours,
Lauernz Albe