Re: Latches vs lwlock contention - Mailing list pgsql-hackers

From Alexander Lakhin
Subject Re: Latches vs lwlock contention
Date
Msg-id e11a30e5-c0d8-491d-8546-3a1b50c10ad4@gmail.com
Whole thread Raw
In response to Re: Latches vs lwlock contention  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Latches vs lwlock contention
List pgsql-hackers
Hello Heikki,

04.11.2024 18:08, Heikki Linnakangas wrote:
> Committed, thanks for the review!

I've discovered that the following script:
export PGOPTIONS='-c lock_timeout=1s'
createdb regression
for i in {1..100}; do
echo "ITERATION: $i"
psql -c "CREATE TABLE t(i int);"
cat << 'EOF' | psql &
DO $$
DECLARE
     i int;
BEGIN
    FOR i IN 1 .. 5000000 LOOP
     INSERT INTO t VALUES (1);
   END LOOP;
END;
$$;
EOF
sleep 1
psql -c "DROP TABLE t" &
cat << 'EOF' | psql &
COPY t FROM STDIN;
0
\.
EOF
wait

psql -c "DROP TABLE t" || break;
done

causes a segmentation fault on master (it fails on iterations 5, 4, 26 for me):
ITERATION: 26
CREATE TABLE
ERROR:  canceling statement due to lock timeout
ERROR:  canceling statement due to lock timeout
invalid command \.
ERROR:  syntax error at or near "0"
LINE 1: 0
         ^
server closed the connection unexpectedly

Core was generated by `postgres: law regression [local] idle                                         '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  GrantLockLocal (locallock=0x5a1d75c35ba8, owner=0x5a1d75c18630) at lock.c:1805
1805            lockOwners[i].owner = owner;
(gdb) bt
#0  GrantLockLocal (locallock=0x5a1d75c35ba8, owner=0x5a1d75c18630) at lock.c:1805
#1  0x00005a1d51e93ee7 in GrantAwaitedLock () at lock.c:1887
#2  0x00005a1d51ea1e58 in LockErrorCleanup () at proc.c:814
#3  0x00005a1d51b9a1a7 in AbortTransaction () at xact.c:2853
#4  0x00005a1d51b9abc6 in AbortCurrentTransactionInternal () at xact.c:3579
#5  AbortCurrentTransaction () at xact.c:3457
#6  0x00005a1d51eafeda in PostgresMain (dbname=<optimized out>, username=0x5a1d75c139b8 "law") at postgres.c:4440

(gdb) p lockOwners
$1 = (LOCALLOCKOWNER *) 0x0

git bisect led me to 3c0fd64fe.
Could you please take a look?

Best regards,
Alexander Lakhin
Neon (https://neon.tech)



pgsql-hackers by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state
Next
From: Sami Imseih
Date:
Subject: Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET