1. TruncateMultiXact() performs the SLRU truncations in a criticalsection. Deleting the SLRU segments calls ForwardSyncRequest(), whichwill try to compact the request queue if it's full(CompactCheckpointerRequestQueue()). That in turn allocates memory,which is not allowed in a critical section. Backtrace:    TRAP: failed Assert("CritSectionCount == 0 || (context)->allowInCritSection"), File: "../src/backend/utils/mmgr/mcxt.c", Line: 1353, PID: 920981    postgres: autovacuum worker template0(ExceptionalCondition+0x6e)[0x560a501e866e]    postgres: autovacuum worker template0(+0x5dce3d)[0x560a50217e3d]    postgres: autovacuum worker template0(ForwardSyncRequest+0x8e)[0x560a4ffec95e]    postgres: autovacuum worker template0(RegisterSyncRequest+0x2b)[0x560a50091eeb]    postgres: autovacuum worker template0(+0x187b0a)[0x560a4fdc2b0a]    postgres: autovacuum worker template0(SlruDeleteSegment+0x101)[0x560a4fdc2ab1]    postgres: autovacuum worker template0(TruncateMultiXact+0x2fb)[0x560a4fdbde1b]    postgres: autovacuum worker template0(vac_update_datfrozenxid+0x4b3)[0x560a4febd2f3]    postgres: autovacuum worker template0(+0x3adf66)[0x560a4ffe8f66]    postgres: autovacuum worker template0(AutoVacWorkerMain+0x3ed)[0x560a4ffe7c2d]    postgres: autovacuum worker template0(+0x3b1ead)[0x560a4ffecead]    postgres: autovacuum worker template0(+0x3b620e)[0x560a4fff120e]    postgres: autovacuum worker template0(+0x3b3fbb)[0x560a4ffeefbb]    postgres: autovacuum worker template0(+0x2f724e)[0x560a4ff3224e]    /lib/x86_64-linux-gnu/libc.so.6(+0x27c8a)[0x7f62cc642c8a]    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85)[0x7f62cc642d45]    postgres: autovacuum worker template0(_start+0x21)[0x560a4fd16f31]To fix, bail out in CompactCheckpointerRequestQueue() without doinganything, if it's called in a critical section. That covers the abovecall path, as well as any other similar cases whereRegisterSyncRequest might be called in a critical section.2. After fixing that, another problem became apparent: Autovacuumprocess doing that truncation can deadlock with the checkpointerprocess. TruncateMultiXact() sets "MyProc->delayChkptFlags |=DELAY_CHKPT_START". If the sync request queue is full and cannot becompacted, the process will repeatedly sleep and retry, until there isroom in the queue. However, if the checkpointer is trying to start acheckpoint at the same time, and is waiting for the DELAY_CHKPT_STARTprocesses to finish, the queue will never shrink.More concretely, the autovacuum process is stuck here:    #0  0x00007fc934926dc3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6#1  0x000056220b24348b in WaitEventSetWaitBlock (set=0x56220c2e4b50, occurred_events=0x7ffe7856d040, nevents=1, cur_timeout=<optimized out>) at ../src/backend/storage/ipc/latch.c:1570#2  WaitEventSetWait (set=0x56220c2e4b50, timeout=timeout@entry=10, occurred_events=<optimized out>, occurred_events@entry=0x7ffe7856d040, nevents=nevents@entry=1,        wait_event_info=wait_event_info@entry=150994949) at ../src/backend/storage/ipc/latch.c:1516#3  0x000056220b243224 in WaitLatch (latch=<optimized out>, latch@entry=0x0, wakeEvents=wakeEvents@entry=40, timeout=timeout@entry=10, wait_event_info=wait_event_info@entry=150994949)        at ../src/backend/storage/ipc/latch.c:538#4  0x000056220b26cf46 in RegisterSyncRequest (ftag=ftag@entry=0x7ffe7856d0a0, type=type@entry=SYNC_FORGET_REQUEST, retryOnError=true) at ../src/backend/storage/sync/sync.c:614#5  0x000056220af9db0a in SlruInternalDeleteSegment (ctl=ctl@entry=0x56220b7beb60 <MultiXactMemberCtlData>, segno=segno@entry=11350) at ../src/backend/access/transam/slru.c:1495postgres#6  0x000056220af9dab1 in SlruDeleteSegment (ctl=ctl@entry=0x56220b7beb60 <MultiXactMemberCtlData>, segno=segno@entry=11350) at ../src/backend/access/transam/slru.c:1566postgres#7  0x000056220af98e1b in PerformMembersTruncation (oldestOffset=<optimized out>, newOldestOffset=<optimized out>) at ../src/backend/access/transam/multixact.c:3006postgres#8  TruncateMultiXact (newOldestMulti=newOldestMulti@entry=3221225472, newOldestMultiDB=newOldestMultiDB@entry=4) at ../src/backend/access/transam/multixact.c:3201postgres#9  0x000056220b098303 in vac_truncate_clog (frozenXID=749, minMulti=<optimized out>, lastSaneFrozenXid=749, lastSaneMinMulti=3221225472) at ../src/backend/commands/vacuum.c:1917postgres#10 vac_update_datfrozenxid () at ../src/backend/commands/vacuum.c:1760postgres#11 0x000056220b1c3f76 in do_autovacuum () at ../src/backend/postmaster/autovacuum.c:2550postgres#12 0x000056220b1c2c3d in AutoVacWorkerMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at ../src/backend/postmaster/autovacuum.c:1569and the checkpointer is stuck here:    #0  0x00007fc9348ebf93 in clock_nanosleep () from /lib/x86_64-linux-gnu/libc.so.6#1  0x00007fc9348fe353 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6#2  0x000056220b40ecb4 in pg_usleep (microsec=microsec@entry=10000) at ../src/port/pgsleep.c:50#3  0x000056220afb43c3 in CreateCheckPoint (flags=flags@entry=108) at ../src/backend/access/transam/xlog.c:7098#4  0x000056220b1c6e86 in CheckpointerMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at ../src/backend/postmaster/checkpointer.c:464To fix, add AbsorbSyncRequests() to the loops where the checkpointerwaits for DELAY_CHKPT_START or DELAY_CHKPT_COMPLETE operations tofinish.Backpatch to v14. Before that, SLRU deletion didn't callRegisterSyncRequest, which avoided this failure. I'm not sure if thereare other similar scenarios on older versions, but we haven't hadany such reports.Discussion:https://www.postgresql.org/message-id/ccc66933-31c1-4f6a-bf4b-45fef0d4f22e@iki.fi

checkExtensionMembership() set the DUMP_COMPONENT_SECLABEL andDUMP_COMPONENT_POLICY flags for extension member objects, even thoughwe lack any infrastructure for tracking extensions' initial settingsof these properties.  This is not OK.  The result was that a dumpwould always include commands to set these properties for extensionobjects that have them, with at least three negative consequences:1. The restoring user might not have privilege to set these propertieson these objects.2. The properties might be incorrect/irrelevant for the version of theextension that's installed in the destination database.3. The dump itself might fail, in the case of RLS properties attachedto extension tables that the dumping user lacks privilege to LOCK.(That's because we must get at least AccessShareLock to ensure thatwe don't fail while trying to decompile the RLS expressions.)When and if somebody cares to invent initial-state infrastructure forextensions' RLS policies and security labels, we could think aboutfinding another way around problem#3.  But in the absence of suchinfrastructure, this whole thing is just wrong and we shouldn't do it.(Note: this applies only to ordinary dumps; binary-upgrade dumpsstill dump and restore extension member objects separately, withall properties.)Tom Lane and Jacob Champion.  Back-patch to all supported branches.Discussion:https://postgr.es/m/00d46a48-3324-d9a0-49bf-e7f0f11d1038@timescale.com

1. TruncateMultiXact() performs the SLRU truncations in a criticalsection. Deleting the SLRU segments calls ForwardSyncRequest(), whichwill try to compact the request queue if it's full(CompactCheckpointerRequestQueue()). That in turn allocates memory,which is not allowed in a critical section. Backtrace:    TRAP: failed Assert("CritSectionCount == 0 || (context)->allowInCritSection"), File: "../src/backend/utils/mmgr/mcxt.c", Line: 1353, PID: 920981    postgres: autovacuum worker template0(ExceptionalCondition+0x6e)[0x560a501e866e]    postgres: autovacuum worker template0(+0x5dce3d)[0x560a50217e3d]    postgres: autovacuum worker template0(ForwardSyncRequest+0x8e)[0x560a4ffec95e]    postgres: autovacuum worker template0(RegisterSyncRequest+0x2b)[0x560a50091eeb]    postgres: autovacuum worker template0(+0x187b0a)[0x560a4fdc2b0a]    postgres: autovacuum worker template0(SlruDeleteSegment+0x101)[0x560a4fdc2ab1]    postgres: autovacuum worker template0(TruncateMultiXact+0x2fb)[0x560a4fdbde1b]    postgres: autovacuum worker template0(vac_update_datfrozenxid+0x4b3)[0x560a4febd2f3]    postgres: autovacuum worker template0(+0x3adf66)[0x560a4ffe8f66]    postgres: autovacuum worker template0(AutoVacWorkerMain+0x3ed)[0x560a4ffe7c2d]    postgres: autovacuum worker template0(+0x3b1ead)[0x560a4ffecead]    postgres: autovacuum worker template0(+0x3b620e)[0x560a4fff120e]    postgres: autovacuum worker template0(+0x3b3fbb)[0x560a4ffeefbb]    postgres: autovacuum worker template0(+0x2f724e)[0x560a4ff3224e]    /lib/x86_64-linux-gnu/libc.so.6(+0x27c8a)[0x7f62cc642c8a]    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85)[0x7f62cc642d45]    postgres: autovacuum worker template0(_start+0x21)[0x560a4fd16f31]To fix, bail out in CompactCheckpointerRequestQueue() without doinganything, if it's called in a critical section. That covers the abovecall path, as well as any other similar cases whereRegisterSyncRequest might be called in a critical section.2. After fixing that, another problem became apparent: Autovacuumprocess doing that truncation can deadlock with the checkpointerprocess. TruncateMultiXact() sets "MyProc->delayChkptFlags |=DELAY_CHKPT_START". If the sync request queue is full and cannot becompacted, the process will repeatedly sleep and retry, until there isroom in the queue. However, if the checkpointer is trying to start acheckpoint at the same time, and is waiting for the DELAY_CHKPT_STARTprocesses to finish, the queue will never shrink.More concretely, the autovacuum process is stuck here:    #0  0x00007fc934926dc3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6#1  0x000056220b24348b in WaitEventSetWaitBlock (set=0x56220c2e4b50, occurred_events=0x7ffe7856d040, nevents=1, cur_timeout=<optimized out>) at ../src/backend/storage/ipc/latch.c:1570#2  WaitEventSetWait (set=0x56220c2e4b50, timeout=timeout@entry=10, occurred_events=<optimized out>, occurred_events@entry=0x7ffe7856d040, nevents=nevents@entry=1,        wait_event_info=wait_event_info@entry=150994949) at ../src/backend/storage/ipc/latch.c:1516#3  0x000056220b243224 in WaitLatch (latch=<optimized out>, latch@entry=0x0, wakeEvents=wakeEvents@entry=40, timeout=timeout@entry=10, wait_event_info=wait_event_info@entry=150994949)        at ../src/backend/storage/ipc/latch.c:538#4  0x000056220b26cf46 in RegisterSyncRequest (ftag=ftag@entry=0x7ffe7856d0a0, type=type@entry=SYNC_FORGET_REQUEST, retryOnError=true) at ../src/backend/storage/sync/sync.c:614#5  0x000056220af9db0a in SlruInternalDeleteSegment (ctl=ctl@entry=0x56220b7beb60 <MultiXactMemberCtlData>, segno=segno@entry=11350) at ../src/backend/access/transam/slru.c:1495postgres#6  0x000056220af9dab1 in SlruDeleteSegment (ctl=ctl@entry=0x56220b7beb60 <MultiXactMemberCtlData>, segno=segno@entry=11350) at ../src/backend/access/transam/slru.c:1566postgres#7  0x000056220af98e1b in PerformMembersTruncation (oldestOffset=<optimized out>, newOldestOffset=<optimized out>) at ../src/backend/access/transam/multixact.c:3006postgres#8  TruncateMultiXact (newOldestMulti=newOldestMulti@entry=3221225472, newOldestMultiDB=newOldestMultiDB@entry=4) at ../src/backend/access/transam/multixact.c:3201postgres#9  0x000056220b098303 in vac_truncate_clog (frozenXID=749, minMulti=<optimized out>, lastSaneFrozenXid=749, lastSaneMinMulti=3221225472) at ../src/backend/commands/vacuum.c:1917postgres#10 vac_update_datfrozenxid () at ../src/backend/commands/vacuum.c:1760postgres#11 0x000056220b1c3f76 in do_autovacuum () at ../src/backend/postmaster/autovacuum.c:2550postgres#12 0x000056220b1c2c3d in AutoVacWorkerMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at ../src/backend/postmaster/autovacuum.c:1569and the checkpointer is stuck here:    #0  0x00007fc9348ebf93 in clock_nanosleep () from /lib/x86_64-linux-gnu/libc.so.6#1  0x00007fc9348fe353 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6#2  0x000056220b40ecb4 in pg_usleep (microsec=microsec@entry=10000) at ../src/port/pgsleep.c:50#3  0x000056220afb43c3 in CreateCheckPoint (flags=flags@entry=108) at ../src/backend/access/transam/xlog.c:7098#4  0x000056220b1c6e86 in CheckpointerMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at ../src/backend/postmaster/checkpointer.c:464To fix, add AbsorbSyncRequests() to the loops where the checkpointerwaits for DELAY_CHKPT_START or DELAY_CHKPT_COMPLETE operations tofinish.Backpatch to v14. Before that, SLRU deletion didn't callRegisterSyncRequest, which avoided this failure. I'm not sure if thereare other similar scenarios on older versions, but we haven't hadany such reports.Discussion:https://www.postgresql.org/message-id/ccc66933-31c1-4f6a-bf4b-45fef0d4f22e@iki.fi