subscription/t/010_truncate.pl failure on desmoxytes in REL_13_STABLE

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: subscription/t/010_truncate.pl failure on desmoxytes in REL_13_STABLE
Date: 2021-06-22 05:02:46
Message-ID: CA+hUKGKfxdQOpVpDhjJvtLThOHykApTN7VAM93zh5Ft-zgWxXQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

While scanning for assertion failures on the build farm that don't
appear to have been discussed, I found this[1] in
010_truncate_publisher.log on the 13 branch:

TRAP: FailedAssertion("tupdesc->tdrefcount <= 0", File:
"/home/bf/build/buildfarm-desmoxytes/REL_13_STABLE/pgsql.build/../pgsql/src/backend/access/common/tupdesc.c",
Line: 321)
2021-06-17 02:17:04.392 CEST [60ca947c.f7a43:4] LOG: server process
(PID 1014658) was terminated by signal 11: Segmentation fault
2021-06-17 02:17:04.392 CEST [60ca947c.f7a43:5] DETAIL: Failed
process was running: SELECT pg_catalog.set_config('search_path', '',
false);

The last thing the segfaulting process said was:

2021-06-17 02:17:03.847 CEST [60ca947f.f7b82:8] LOG: logical decoding
found consistent point at 0/157D538
2021-06-17 02:17:03.847 CEST [60ca947f.f7b82:9] DETAIL: There are no
running transactions.

Unfortunately 13 doesn't log PIDs for assertion failures (hmm, commit
18c170a08ee could be back-patched?) so it's not clear which process
that was, and there's no backtrace.

I don't know if "pg_catalog.set_config('search_path', '', false)" is a
clue that this is related to another recent crash[2] I mentioned, also
from the 13 branch.

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=desmoxytes&dt=2021-06-16%2023:58:47
[2] https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BqdF6QE6rcj_Zj5h2qVARM--%2B92sqdmr-0DUSM_0Qu_g%40mail.gmail.com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-06-22 05:06:57 Re: Doc chapter for Hash Indexes
Previous Message Thomas Munro 2021-06-22 05:01:44 Re: fdatasync performance problem with large number of DB files