From: Alexander Lakhin <exclusion@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Ronan Dunklau <ronan.dunklau@aiven.io>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Failures in constraints regression test, "read only 0 of 8192 bytes"
Date: Wed, 19 Jun 2024 23:00:00 +0300
Message-ID: <987b1c8c-8c91-4847-ca0e-879f421680ff@gmail.com> (raw)
In-Reply-To: <e9847a44-8f69-483f-92dc-5a2ca0a8be59@iki.fi>
References: <CA+hUKGK+5DOmLaBp3Z7C4S-Yv6yoROvr1UncjH2S1ZbPT8D+Zg@mail.gmail.com>
<e4f94648-4236-4358-b64c-6a935e33658d@enterprisedb.com>
<2185821.Icojqenx9y@aivenlaptop>
<5c5a0015-723a-4fa7-85d5-2f0f47b92094@enterprisedb.com>
<CA+hUKGJvFgkEgbKyPZj4CwjN9=A+ggio3_2xdwnK0Gd8RzAYuw@mail.gmail.com>
<deefcee6-c8bb-40ed-a4e5-6c20648cf043@enterprisedb.com>
<61ef0b89-1ec6-4d88-afbd-2ffc2c977511@enterprisedb.com>
<CA+hUKGKKQJRap2M5EE7XoQRn5-O0h1=p0wkpkGog=87me-g6+g@mail.gmail.com>
<05fd672f-2eac-4758-91e9-fa7afafa147e@enterprisedb.com>
<CA+hUKGKdOS9xccxast-L-MLN3=yA0TYpm=cRhpo_FCq6+O-jQA@mail.gmail.com>
<CA+hUKG+XOrCi3UwiK5dNL_B8Eav6hMk334L4Qpctfw4MPDUYaw@mail.gmail.com>
<CA+hUKGL0dBL-+0_GoN9H_9s0Fx3iOQu28D7Y5o=W0QyP2+s8iQ@mail.gmail.com>
<de4070e3-d468-4284-a778-8b8025db41f1@iki.fi>
<50ebc494-0d52-4b76-bea4-f7ab5569300a@iki.fi>
<CA+hUKGJU1hb2jZQWEDniUEU2E1sz_8gUhccg7+Uj0kzBeSCPJA@mail.gmail.com>
<e9847a44-8f69-483f-92dc-5a2ca0a8be59@iki.fi>
Hello Heikki,
11.03.2024 10:09, Heikki Linnakangas wrote:
> On 10/03/2024 22:59, Thomas Munro wrote:
>> On Mon, Mar 11, 2024 at 9:30 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>> Barring objections, I'll commit the attached.
>>
>> +1
>
> Pushed, thanks!
Please look at a new anomaly, that I've discovered in master.
Starting from af0e7deb4, the following script:
numjobs=80
for ((i=1;i<=50;i++)); do
echo "I $i"
for ((j=1;j<=numjobs;j++)); do createdb db$j; done
for ((j=1;j<=numjobs;j++)); do
echo "
VACUUM FULL pg_class;
REINDEX INDEX pg_class_oid_index;
" | psql -d db$j >/dev/null 2>&1 &
echo "
CREATE TABLE tbl1 (t text);
DROP TABLE tbl1;
" | psql -d db$j >/dev/null 2>&1 &
done
wait
grep 'was terminated' server.log && break;
for ((j=1;j<=numjobs;j++)); do dropdb db$j; done
done
triggers a segfault:
2024-06-19 19:22:49.009 UTC [1607210:6] LOG: server process (PID 1607671) was terminated by signal 11: Segmentation fault
with the following stack trace:
Core was generated by `postgres: law db50 [local] CREATE TABLE '.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Section `.reg-xstate/1607671' in core file too small.
#0 0x000055d04cb8232e in RelationReloadNailed (relation=0x7f7d0a1b1fd8) at relcache.c:2415
2415 relp = (Form_pg_class) GETSTRUCT(pg_class_tuple);
(gdb) bt
#0 0x000055d04cb8232e in RelationReloadNailed (relation=0x7f7d0a1b1fd8) at relcache.c:2415
#1 0x000055d04cb8278c in RelationClearRelation (relation=0x7f7d0a1b1fd8, rebuild=true) at relcache.c:2560
#2 0x000055d04cb834e9 in RelationCacheInvalidate (debug_discard=false) at relcache.c:3048
#3 0x000055d04cb72e3c in InvalidateSystemCachesExtended (debug_discard=false) at inval.c:680
#4 0x000055d04cb73190 in InvalidateSystemCaches () at inval.c:794
#5 0x000055d04c9754ad in ReceiveSharedInvalidMessages (
invalFunction=0x55d04cb72eee <LocalExecuteInvalidationMessage>,
resetFunction=0x55d04cb7317e <InvalidateSystemCaches>) at sinval.c:105
#6 0x000055d04cb731b4 in AcceptInvalidationMessages () at inval.c:808
#7 0x000055d04c97d2ed in LockRelationOid (relid=2662, lockmode=1) at lmgr.c:136
#8 0x000055d04c404b1f in relation_open (relationId=2662, lockmode=1) at relation.c:55
#9 0x000055d04c47941e in index_open (relationId=2662, lockmode=1) at indexam.c:137
#10 0x000055d04c4787c2 in systable_beginscan (heapRelation=0x7f7d0a1b1fd8, indexId=2662, indexOK=true, snapshot=0x0,
nkeys=1, key=0x7ffd456a8570) at genam.c:396
#11 0x000055d04cb7e93d in ScanPgRelation (targetRelId=3466, indexOK=true, force_non_historic=false) at relcache.c:381
#12 0x000055d04cb7fe15 in RelationBuildDesc (targetRelId=3466, insertIt=true) at relcache.c:1093
#13 0x000055d04cb81c93 in RelationIdGetRelation (relationId=3466) at relcache.c:2108
#14 0x000055d04c404b29 in relation_open (relationId=3466, lockmode=1) at relation.c:58
#15 0x000055d04cb720a6 in BuildEventTriggerCache () at evtcache.c:129
#16 0x000055d04cb71f6a in EventCacheLookup (event=EVT_SQLDrop) at evtcache.c:68
#17 0x000055d04c61c037 in trackDroppedObjectsNeeded () at event_trigger.c:1342
#18 0x000055d04c61bf02 in EventTriggerBeginCompleteQuery () at event_trigger.c:1284
#19 0x000055d04c9ac744 in ProcessUtilitySlow (pstate=0x55d04d04aca0, pstmt=0x55d04d021540,
queryString=0x55d04d020830 "CREATE TABLE tbl1 (t text);", context=PROCESS_UTILITY_TOPLEVEL, params=0x0,
queryEnv=0x0, dest=0x55d04d021800, qc=0x7ffd456a8fb0) at utility.c:1107
#20 0x000055d04c9ac64d in standard_ProcessUtility (pstmt=0x55d04d021540,
queryString=0x55d04d020830 "CREATE TABLE tbl1 (t text);", readOnlyTree=false, context=PROCESS_UTILITY_TOPLEVEL,
params=0x0, queryEnv=0x0, dest=0x55d04d021800, qc=0x7ffd456a8fb0) at utility.c:1067
#21 0x000055d04c9ab54d in ProcessUtility (pstmt=0x55d04d021540,
queryString=0x55d04d020830 "CREATE TABLE tbl1 (t text);", readOnlyTree=false, context=PROCESS_UTILITY_TOPLEVEL,
params=0x0, queryEnv=0x0, dest=0x55d04d021800, qc=0x7ffd456a8fb0) at utility.c:523
#22 0x000055d04c9a9dc6 in PortalRunUtility (portal=0x55d04d0c1020, pstmt=0x55d04d021540, isTopLevel=true,
setHoldSnapshot=false, dest=0x55d04d021800, qc=0x7ffd456a8fb0) at pquery.c:1158
#23 0x000055d04c9aa03d in PortalRunMulti (portal=0x55d04d0c1020, isTopLevel=true, setHoldSnapshot=false,
dest=0x55d04d021800, altdest=0x55d04d021800, qc=0x7ffd456a8fb0) at pquery.c:1315
#24 0x000055d04c9a9487 in PortalRun (portal=0x55d04d0c1020, count=9223372036854775807, isTopLevel=true, run_once=true,
dest=0x55d04d021800, altdest=0x55d04d021800, qc=0x7ffd456a8fb0) at pquery.c:791
#25 0x000055d04c9a2150 in exec_simple_query (query_string=0x55d04d020830 "CREATE TABLE tbl1 (t text);")
at postgres.c:1273
#26 0x000055d04c9a71f5 in PostgresMain (dbname=0x55d04d05dbf0 "db50", username=0x55d04d05dbd8 "law") at postgres.c:4675
#27 0x000055d04c8bd8c8 in BackendRun (port=0x55d04d0540c0) at postmaster.c:4475
#28 0x000055d04c8bcedd in BackendStartup (port=0x55d04d0540c0) at postmaster.c:4151
#29 0x000055d04c8b93a9 in ServerLoop () at postmaster.c:1769
#30 0x000055d04c8b8ca4 in PostmasterMain (argc=3, argv=0x55d04d01a770) at postmaster.c:1468
#31 0x000055d04c76c577 in main (argc=3, argv=0x55d04d01a770) at main.c:197
(gdb) p pg_class_tuple
$1 = (HeapTuple) 0x0
server.log might also contain:
2024-06-19 19:25:38.060 UTC [1618682:5] psql ERROR: could not read blocks 3..3 in file "base/28531/28840": read only 0
of 8192 bytes
Best regards,
Alexander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: exclusion@gmail.com, hlinnaka@iki.fi, thomas.munro@gmail.com, tomas.vondra@enterprisedb.com, ronan.dunklau@aiven.io, pgsql-hackers@lists.postgresql.org
Subject: Re: Failures in constraints regression test, "read only 0 of 8192 bytes"
In-Reply-To: <987b1c8c-8c91-4847-ca0e-879f421680ff@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox