Message-ID: <dd36d384-55df-4fc2-825c-5bc56c950fa9@gmail.com>
Date: Sun, 2 Nov 2025 12:00:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Improve LWLock tranche name visibility across backends
To: Nathan Bossart <nathandbossart@gmail.com>,
 Sami Imseih <samimseih@gmail.com>
Cc: Rahila Syed <rahilasyed90@gmail.com>,
 Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Tom Lane
 <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: 
 <CAA5RZ0s4ip08Lsk=aYuXGCkBr78jhH=gOau939mhAp-rGuNC3Q@mail.gmail.com>
 <aLCEo0ZMV3vIGRWk@nathan>
 <CAA5RZ0vw-r1qjHw5hUNTzAyCiK3KQ-r+G5ECfWSn+qjdu-fpnw@mail.gmail.com>
 <aLHO-jh-spXWG1pt@nathan> <aLJnOnTFSweb2pud@nathan>
 <CAH2L28sz2NcLCS2v1MNkBNUiTiO=-CegFGdAvO24nE+hbjzgjQ@mail.gmail.com>
 <aLcPbyWLawp5_rdt@nathan> <aLiQeizOQKbKF-ae@nathan> <aLmzwC2dRbqk14y6@nathan>
 <CAA5RZ0t6s2Z38oRq883Ocq7J4xjn1FJF17Q4YR6++vrw5KYCtQ@mail.gmail.com>
 <aLn4n-5UFzKHFdR5@nathan>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <aLn4n-5UFzKHFdR5@nathan>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/dd36d384-55df-4fc2-825c-5bc56c950fa9%40gmail.com>
Precedence: bulk

Hello Nathan,

04.09.2025 23:37, Nathan Bossart wrote:
> On Thu, Sep 04, 2025 at 12:30:27PM -0500, Sami Imseih wrote:
>> I liked removing the repalloc calls inside this routine and did not think
>> it was worth optimizing. I am OK with reverting it back. Although v1
>> is incorrect since it's still initializing
>> NamedLWLockTrancheRequestArray to MAX_NAMED_TRANCHES
> Committed with that fix.
>
>>> Furthermore, the
>>> MAX_NAMED_TRANCHES check isn't actually needed because InitializeLWLocks()
>>> will do the same check via its calls to LWLockNewTrancheId() for all the
>>> named tranche requests.
>> I thought about that one and decided to add the error message there, since
>> requesting a tranche happens way before LWLockNewTrancheId is called
>> during CreateLWLocks, so it was more about erroring out slightly earlier.
>> But it may be ok to also just remove it.
> We needed it before because the array could only ever hold
> MAX_NAMED_TRANCHES requests.

I've discovered (with SQLsmith) that the new possible error makes
pg_prewarm/autoprewarm fail when the error triggered during it's
initialization and then another instance tries to acquire apw_state->lock.

Please try the following:
psql -c "CREATE EXTENSION test_dsa; CREATE EXTENSION pg_prewarm;"

psql -c "SELECT test_dsa_resowners() FROM generate_series(1, 256)" >/dev/null

psql -c "SELECT pg_sleep(0.5); SELECT autoprewarm_dump_now()" &

psql -c "SELECT pg_sleep(1); SELECT autoprewarm_dump_now()"

with
debug_parallel_query = 'on'
min_dynamic_shared_memory = '1GB'
in postgresql.conf

it causes PANIC for me (on roughly 5 out or 10 runs) as below:
CREATE EXTENSION
CREATE EXTENSION
  pg_sleep
----------

(1 row)

ERROR:  maximum number of tranches already registered
DETAIL:  No more than 256 tranches may be registered.
  pg_sleep
----------

(1 row)

server closed the connection unexpectedly
         This probably means the server terminated abnormally
         before or while processing the request.

PANIC:  stuck spinlock detected at LWLockWaitListLock, lwlock.c:882
...
#5  0x000057831e809d1d in errfinish (filename=0x57831ea53edd "s_lock.c", lineno=89, funcname=0x57831ea53ee8 <__func__.0> 
"s_lock_stuck") at elog.c:609
#6  0x000057831e5f2185 in s_lock_stuck (file=0x57831ea5184c "lwlock.c", line=882, func=0x57831ea51c30 <__func__.5> 
"LWLockWaitListLock") at s_lock.c:89
#7  0x000057831e5f2291 in perform_spin_delay (status=0x7ffdf9fabbe0) at s_lock.c:135
#8  0x000057831e5e4015 in LWLockWaitListLock (lock=0x736a16ad6500) at lwlock.c:886
#9  0x000057831e5e4475 in LWLockQueueSelf (lock=0x736a16ad6500, mode=LW_EXCLUSIVE) at lwlock.c:1055
#10 0x000057831e5e4728 in LWLockAcquire (lock=0x736a16ad6500, mode=LW_EXCLUSIVE) at lwlock.c:1259
#11 0x0000736a63dbcc82 in apw_dump_now (is_bgworker=false, dump_unlogged=true) at autoprewarm.c:676
#12 0x0000736a63dbd5c9 in autoprewarm_dump_now (fcinfo=0x57835c770fe8) at autoprewarm.c:854
...

Best regards,
Alexander