Message-ID: <987b1c8c-8c91-4847-ca0e-879f421680ff@gmail.com>
Date: Wed, 19 Jun 2024 23:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: Failures in constraints regression test, "read only 0 of 8192
 bytes"
To: Heikki Linnakangas <hlinnaka@iki.fi>,
 Thomas Munro <thomas.munro@gmail.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>,
 Ronan Dunklau <ronan.dunklau@aiven.io>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
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>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <e9847a44-8f69-483f-92dc-5a2ca0a8be59@iki.fi>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/987b1c8c-8c91-4847-ca0e-879f421680ff%40gmail.com>
Precedence: bulk

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