Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rJxLN-00HDS8-9g for pgsql-bugs@arkaria.postgresql.org; Sun, 31 Dec 2023 15:03:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rJxLL-008TzM-Mi for pgsql-bugs@arkaria.postgresql.org; Sun, 31 Dec 2023 15:03:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rJxLL-008TzC-1m for pgsql-bugs@lists.postgresql.org; Sun, 31 Dec 2023 15:03:11 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rJxLC-00D4h5-JX for pgsql-bugs@lists.postgresql.org; Sun, 31 Dec 2023 15:03:09 +0000 Received: from [192.168.96.6] (unknown [77.50.64.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: m.zhilin@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id B6FE3E2105B for ; Sun, 31 Dec 2023 18:02:58 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1704034978; bh=nEYMJkvQ+r3RwAvj3tSVwX6h/ciLazvX5uMCr7dGkjQ=; h=Message-ID:Date:User-Agent:From:Subject:To:From; b=G1bvCrRzO4a0Hg4xjJABISYxR0rBTDjjUgTggsV2tPQkPy44BVOFY6gN53kahH5HF RDp81hV50bg0lq03tnCPzWDJU3j6QFf7/2nhfr78J1mE7LvmFUw7P39EpHDMt+58zV bPhpLB+2zDE/3Yh4kRzDO6crkK7+rdLSgWH4IXNz0hjgYerXGCZvEdLAPLbr2ZLLcc 09vyxgdIIH8Ub8dJxZ4ZD7JJUg0R69xuDkzE+svLrtB+nLbSbqEghKkRNpuaQ2S27J UpEo4+tPQ8zlkQJdQcp/54Qu/6ekVyJQ8gctV/KB9JqgYTd7i4YCeauhKZIdV9hZOO uOPrNA7NL15dA== Content-Type: multipart/mixed; boundary="------------0vFEpECx7jrNQMWp17f0L0SK" Message-ID: Date: Sun, 31 Dec 2023 18:02:58 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Michael Zhilin Subject: BUG: deadlock between autovacuum worker and client backend during removal of orphan temp tables with sequences To: pgsql-bugs@lists.postgresql.org List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------0vFEpECx7jrNQMWp17f0L0SK Content-Type: multipart/alternative; boundary="------------5AExjHkOI0kzxDHDp0ZDXKKm" --------------5AExjHkOI0kzxDHDp0ZDXKKm Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi pgsql-bugs, Several customers reported deadlock error raised after accidental restart of server. Problem description -------------------- Client backend tries to create first temporary table after connection and it gets deadlock error. Here is example of log file records: 2023-12-29 13:48:21.977 MSK [29546] ERROR:  deadlock detected at character 24 2023-12-29 13:48:21.977 MSK [29546] DETAIL:  Process 29546 waits for AccessExclusiveLock on relation 416811 of database 5; blocked by process 29513.         Process 29513 waits for AccessExclusiveLock on relation 416795 of database 5; blocked by process 29546.         Process 29546: create temporary table tt1 (c1 bytea, c2 bytea, c3 bytea, c4 bytea, c5 numeric(7, 0), c6 serial4 ) without oids;         Process 29513: 29546 is PID of client backend, 29513 is PID of autovacuum worker. Client backend tries to initialize namespace and cleans up all orphan objects into its temporary namespace. Whole cleanup is performed in scope of client transaction. Autovacuum worker tries to remove tables one-by-one, using one transaction for each table. How to reproduce ----------------- To reproduce it, use pgbench and attached SQL file. Start pgbench with following arguments:  $ pgbench -n -j 1 -c 50 -T 10 -C -f create_temp_tables.sql --verbose-errors Kill postgres processes to make table orphan. For local connections the following command can be used:  $ pkill -9  -f "postgres.*local" Wait a bit for recovery completion and start pgbench again:  $ pgbench -n -j 1 -c 50 -T 10 -C -f create_temp_tables.sql --verbose-errors And check log files for deadlock. As autovacuum start is hardly predictable, the launcher nap time is better to set to 1:  # alter system set autovacuum_naptime=1; I've noticed that preliminary "vacuum database" helps to reproduce it. Here is all my custom parameters: alter system set autovacuum_naptime=1; alter system set max_connections to 1000; alter system set backtrace_functions to 'DeadLockReport'; alter system set logging_collector to on; alter system set log_filename to 'postgresql-%Y-%m-%d.log'; alter system set autovacuum_max_workers to 1; Stack traces -------------- Client backend has following stack trace (thanks to backtrace_functions:         0xafbe7e at /opt/pgpro/mybuild/bin/postgres         0xb00dd0 at /opt/pgpro/mybuild/bin/postgres         0xaff983 at /opt/pgpro/mybuild/bin/postgres         0xafd2f9 at /opt/pgpro/mybuild/bin/postgres         0x742a07 at /opt/pgpro/mybuild/bin/postgres         0x7422a4 at /opt/pgpro/mybuild/bin/postgres         0x754624 at /opt/pgpro/mybuild/bin/postgres         0x754424 at /opt/pgpro/mybuild/bin/postgres         0x754f6c at /opt/pgpro/mybuild/bin/postgres         0x7d36b0 at /opt/pgpro/mybuild/bin/postgres         0xb2a05f at /opt/pgpro/mybuild/bin/postgres         0xb28450 at /opt/pgpro/mybuild/bin/postgres         0xb27ea8 at /opt/pgpro/mybuild/bin/postgres         0xb2745b at /opt/pgpro/mybuild/bin/postgres         0xb2681c at /opt/pgpro/mybuild/bin/postgres         0xb25eb8 at /opt/pgpro/mybuild/bin/postgres         0xb24127 at /opt/pgpro/mybuild/bin/postgres         0xb2170e at /opt/pgpro/mybuild/bin/postgres         0xa4e4f8 at /opt/pgpro/mybuild/bin/postgres         0xa4dabf at /opt/pgpro/mybuild/bin/postgres         0xa4a824 at /opt/pgpro/mybuild/bin/postgres         0x93a58a at /opt/pgpro/mybuild/bin/postgres         0x82b77d36a <__libc_start1+0x12a> at /lib/libc.so.7 Autovacuum worker (got by increase deadlock timeout and debugger):         WaitEventSetWaitBlock() at latch.c:1,649 0xae6ffb         WaitEventSetWait() at latch.c:1,435 0xae6ffb         WaitLatch() at latch.c:497 0xae6cc4         ProcSleep() at proc.c:1,341 0xb135de         WaitOnLock() at lock.c:1,859 0xb00d7d         LockAcquireExtended() at lock.c:1,101 0xaffa03         LockRelationOid() at lmgr.c:117 0xafd379         AcquireDeletionLock() at dependency.c:1,552 0x742a37         findDependentObjects() at dependency.c:894 0x742a37         performDeletion() at dependency.c:346 0x7422d4         do_autovacuum() at autovacuum.c:2,274 0xa41f5d         AutoVacWorkerMain() at autovacuum.c:1,716 0xa40200         StartAutoVacWorker() at autovacuum.c:1,494 0xa3fe26         StartAutovacuumWorker() at postmaster.c:5,463 0xa4b5e1         sigusr1_handler() at postmaster.c:5,172 0xa4b5e1         handle_signal() at thr_sig.c:301 0x82980755f         thr_sighandler() at thr_sig.c:244 0x829806b1b Reason ------- Table contains columns with serial type, i.e. with autogenerated sequences. When backend tries to clean namespace, it removes tables and sequences in random way. When autovacuum worker tries to remove table, at first it locks table, then tries to remove sequence by dependency. So it may happen that:  - Backend locks and removes sequence  - Autovacuum worker locks table to remove, finds sequence and tries to remove sequence and get locked.  - Backend tries to lock table locked by autovacuum worker and get locked. Idea how to fix it ------------------ As of now, autovacuum worker tries to avoid concurrency by preliminary conditional lock of table. It provides guarantee to avoid concurrency with other workers. To avoid concurrency with client backend during orphan table removal, it may be worth to conditionally lock namespace before removal attempt. If backend starts namespace removal, it locks namespace exclusively and autovacuum worker can identify it by conditional locking and can skip removal. On another hand, if worker gets namespace lock, then there is no backend removing orphan tables. Also it may worth to mention that worker can try to get AccessShare lock to allow concurrency between workers. Please find attached patch for this idea. Please feel free to ask any questions! Thank you! -- Michael Zhilin Postgres Professional https://www.postgrespro.ru --------------5AExjHkOI0kzxDHDp0ZDXKKm Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi pgsql-bugs,

Several customers reported deadlock error raised after accidental restart of server.

Problem description
--------------------

Client backend tries to create first temporary table after connection and it gets deadlock error.
Here is example of log file records:

2023-12-29 13:48:21.977 MSK [29546] ERROR:  deadlock detected at character 24
2023-12-29 13:48:21.977 MSK [29546] DETAIL:  Process 29546 waits for AccessExclusiveLock on relation 416811 of database 5; blocked by process 29513.
        Process 29513 waits for AccessExclusiveLock on relation 416795 of database 5; blocked by process 29546.
        Process 29546: create temporary table tt1 (c1 bytea, c2 bytea, c3 bytea, c4 bytea, c5 numeric(7, 0), c6 serial4 ) without oids;
        Process 29513: <command string not enabled>

29546 is PID of client backend, 29513 is PID of autovacuum worker.

Client backend tries to initialize namespace and cleans up all orphan objects into its temporary namespace. Whole cleanup is performed in scope of client transaction.
Autovacuum worker tries to remove tables one-by-one, using one transaction for each table.

How to reproduce
-----------------

To reproduce it, use pgbench and attached SQL file. Start pgbench with following arguments:
 $ pgbench -n -j 1 -c 50 -T 10 -C -f create_temp_tables.sql --verbose-errors

Kill postgres processes to make table orphan. For local connections the following command can be used:

 $ pkill -9  -f "postgres.*local"

Wait a bit for recovery completion and start pgbench again:

 $ pgbench -n -j 1 -c 50 -T 10 -C -f create_temp_tables.sql --verbose-errors

And check log files for deadlock. As autovacuum start is hardly predictable, the launcher nap time is better to set to 1:

 # alter system set autovacuum_naptime=1;

I've noticed that preliminary "vacuum database" helps to reproduce it.

Here is all my custom parameters:
alter system set autovacuum_naptime=1;
alter system set max_connections to 1000;
alter system set backtrace_functions to 'DeadLockReport';
alter system set logging_collector to on;
alter system set log_filename to 'postgresql-%Y-%m-%d.log';
alter system set autovacuum_max_workers to 1;

Stack traces
--------------

Client backend has following stack trace (thanks to backtrace_functions:
        0xafbe7e <DeadLockReport+0x27e> at /opt/pgpro/mybuild/bin/postgres
        0xb00dd0 <GrantAwaitedLock> at /opt/pgpro/mybuild/bin/postgres
        0xaff983 <LockAcquireExtended+0x603> at /opt/pgpro/mybuild/bin/postgres
        0xafd2f9 <LockRelationOid+0x69> at /opt/pgpro/mybuild/bin/postgres
        0x742a07 <findDependentObjects+0x627> at /opt/pgpro/mybuild/bin/postgres
        0x7422a4 <performDeletion+0xf4> at /opt/pgpro/mybuild/bin/postgres
        0x754624 <AccessTempTableNamespace+0x134> at /opt/pgpro/mybuild/bin/postgres
        0x754424 <RangeVarGetCreationNamespace+0xa4> at /opt/pgpro/mybuild/bin/postgres
        0x754f6c <RangeVarGetAndCheckCreationNamespace+0x5c> at /opt/pgpro/mybuild/bin/postgres
        0x7d36b0 <transformCreateStmt+0x50> at /opt/pgpro/mybuild/bin/postgres
        0xb2a05f <ProcessUtilitySlow+0xdf> at /opt/pgpro/mybuild/bin/postgres
        0xb28450 <standard_ProcessUtility+0x530> at /opt/pgpro/mybuild/bin/postgres
        0xb27ea8 <ProcessUtility+0x68> at /opt/pgpro/mybuild/bin/postgres
        0xb2745b <PortalRunUtility+0xab> at /opt/pgpro/mybuild/bin/postgres
        0xb2681c <PortalRunMulti+0x1fc> at /opt/pgpro/mybuild/bin/postgres
        0xb25eb8 <PortalRun+0x1e8> at /opt/pgpro/mybuild/bin/postgres
        0xb24127 <exec_simple_query+0x5c7> at /opt/pgpro/mybuild/bin/postgres
        0xb2170e <PostgresMain+0x119e> at /opt/pgpro/mybuild/bin/postgres
        0xa4e4f8 <BackendRun+0x38> at /opt/pgpro/mybuild/bin/postgres
        0xa4dabf <ServerLoop+0xdef> at /opt/pgpro/mybuild/bin/postgres
        0xa4a824 <PostmasterMain+0x1594> at /opt/pgpro/mybuild/bin/postgres
        0x93a58a <main+0x33a> at /opt/pgpro/mybuild/bin/postgres
        0x82b77d36a <__libc_start1+0x12a> at /lib/libc.so.7

Autovacuum worker (got by increase deadlock timeout and debugger):

        WaitEventSetWaitBlock() at latch.c:1,649 0xae6ffb   
        WaitEventSetWait() at latch.c:1,435 0xae6ffb   
        WaitLatch() at latch.c:497 0xae6cc4   
        ProcSleep() at proc.c:1,341 0xb135de   
        WaitOnLock() at lock.c:1,859 0xb00d7d   
        LockAcquireExtended() at lock.c:1,101 0xaffa03   
        LockRelationOid() at lmgr.c:117 0xafd379   
        AcquireDeletionLock() at dependency.c:1,552 0x742a37   
        findDependentObjects() at dependency.c:894 0x742a37   
        performDeletion() at dependency.c:346 0x7422d4   
        do_autovacuum() at autovacuum.c:2,274 0xa41f5d   
        AutoVacWorkerMain() at autovacuum.c:1,716 0xa40200   
        StartAutoVacWorker() at autovacuum.c:1,494 0xa3fe26   
        StartAutovacuumWorker() at postmaster.c:5,463 0xa4b5e1   
        sigusr1_handler() at postmaster.c:5,172 0xa4b5e1   
        handle_signal() at thr_sig.c:301 0x82980755f   
        thr_sighandler() at thr_sig.c:244 0x829806b1b  

Reason
-------

Table contains columns with serial type, i.e. with autogenerated sequences. When backend tries to clean namespace,
it removes tables and sequences in random way. When autovacuum worker tries to remove table, at first it locks table,
then tries to remove sequence by dependency.

So it may happen that:
 - Backend locks and removes sequence
 - Autovacuum worker locks table to remove, finds sequence and tries to remove sequence and get locked.
 - Backend tries to lock table locked by autovacuum worker and get locked.

Idea how to fix it
------------------

As of now, autovacuum worker tries to avoid concurrency by preliminary conditional lock of table. It provides guarantee to
avoid concurrency with other workers. To avoid concurrency with client backend during orphan table removal, it may be worth
to conditionally lock namespace before removal attempt.

If backend starts namespace removal, it locks namespace exclusively and autovacuum worker can identify it by conditional locking and can skip removal.
On another hand, if worker gets namespace lock, then there is no backend removing orphan tables.

Also it may worth to mention that worker can try to get AccessShare lock to allow concurrency between workers.

Please find attached patch for this idea.

Please feel free to ask any questions!

Thank you!

 
-- 
Michael Zhilin
Postgres Professional
https://www.postgrespro.ru
--------------5AExjHkOI0kzxDHDp0ZDXKKm-- --------------0vFEpECx7jrNQMWp17f0L0SK Content-Type: application/sql; name="create_temp_tables.sql" Content-Disposition: attachment; filename="create_temp_tables.sql" Content-Transfer-Encoding: base64 ZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQxIGNhc2NhZGU7IGNyZWF0ZSB0ZW1wb3JhcnkgdGFi bGUgdHQxIChjMSBieXRlYSwgYzIgYnl0ZWEsIGMzIGJ5dGVhLCBjNCBieXRlYSwgYzUgbnVt ZXJpYyg3LCAwKSwgYzYgc2VyaWFsNCApIHdpdGhvdXQgb2lkczsgCmRyb3AgdGFibGUgaWYg ZXhpc3RzIHR0MiBjYXNjYWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0MiAoYzEgYnl0 ZWEsIGMyIGJ5dGVhLCBjMyBieXRlYSwgYzQgYnl0ZWEsIGM1IG51bWVyaWMoNywgMCksIGM2 IHNlcmlhbDQgKSB3aXRob3V0IG9pZHM7IApkcm9wIHRhYmxlIGlmIGV4aXN0cyB0dDMgY2Fz Y2FkZTsgY3JlYXRlIHRlbXBvcmFyeSB0YWJsZSB0dDMgKGMxIGJ5dGVhLCBjMiBieXRlYSwg YzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0 aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQ0IGNhc2NhZGU7IGNyZWF0ZSB0 ZW1wb3JhcnkgdGFibGUgdHQ0IChjMSBieXRlYSwgYzIgYnl0ZWEsIGMzIGJ5dGVhLCBjNCBi eXRlYSwgYzUgbnVtZXJpYyg3LCAwKSwgYzYgc2VyaWFsNCApIHdpdGhvdXQgb2lkczsgCmRy b3AgdGFibGUgaWYgZXhpc3RzIHR0NSBjYXNjYWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRhYmxl IHR0NSAoYzEgYnl0ZWEsIGMyIGJ5dGVhLCBjMyBieXRlYSwgYzQgYnl0ZWEsIGM1IG51bWVy aWMoNywgMCksIGM2IHNlcmlhbDQgKSB3aXRob3V0IG9pZHM7IApkcm9wIHRhYmxlIGlmIGV4 aXN0cyB0dDYgY2FzY2FkZTsgY3JlYXRlIHRlbXBvcmFyeSB0YWJsZSB0dDYgKGMxIGJ5dGVh LCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBz ZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQ3IGNhc2Nh ZGU7IGNyZWF0ZSB0ZW1wb3JhcnkgdGFibGUgdHQ3IChjMSBieXRlYSwgYzIgYnl0ZWEsIGMz IGJ5dGVhLCBjNCBieXRlYSwgYzUgbnVtZXJpYyg3LCAwKSwgYzYgc2VyaWFsNCApIHdpdGhv dXQgb2lkczsgCmRyb3AgdGFibGUgaWYgZXhpc3RzIHR0OCBjYXNjYWRlOyBjcmVhdGUgdGVt cG9yYXJ5IHRhYmxlIHR0OCAoYzEgYnl0ZWEsIGMyIGJ5dGVhLCBjMyBieXRlYSwgYzQgYnl0 ZWEsIGM1IG51bWVyaWMoNywgMCksIGM2IHNlcmlhbDQgKSB3aXRob3V0IG9pZHM7IApkcm9w IHRhYmxlIGlmIGV4aXN0cyB0dDkgY2FzY2FkZTsgY3JlYXRlIHRlbXBvcmFyeSB0YWJsZSB0 dDkgKGMxIGJ5dGVhLCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmlj KDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlz dHMgdHQxMCBjYXNjYWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0MTAgKGMxIGJ5dGVh LCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBz ZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQxMSBjYXNj YWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0MTEgKGMxIGJ5dGVhLCBjMiBieXRlYSwg YzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0 aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQxMiBjYXNjYWRlOyBjcmVhdGUg dGVtcG9yYXJ5IHRhYmxlIHR0MTIgKGMxIGJ5dGVhLCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0 IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAK ZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQxMyBjYXNjYWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRh YmxlIHR0MTMgKGMxIGJ5dGVhLCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBu dW1lcmljKDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBp ZiBleGlzdHMgdHQxNCBjYXNjYWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0MTQgKGMx IGJ5dGVhLCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmljKDcsIDAp LCBjNiBzZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQx NSBjYXNjYWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0MTUgKGMxIGJ5dGVhLCBjMiBi eXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBzZXJpYWw0 ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQxNiBjYXNjYWRlOyBj cmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0MTYgKGMxIGJ5dGVhLCBjMiBieXRlYSwgYzMgYnl0 ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0aG91dCBv aWRzOyAKZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQxNyBjYXNjYWRlOyBjcmVhdGUgdGVtcG9y YXJ5IHRhYmxlIHR0MTcgKGMxIGJ5dGVhLCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVh LCBjNSBudW1lcmljKDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0 YWJsZSBpZiBleGlzdHMgdHQxOCBjYXNjYWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0 MTggKGMxIGJ5dGVhLCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmlj KDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlz dHMgdHQxOSBjYXNjYWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0MTkgKGMxIGJ5dGVh LCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBz ZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQyMCBjYXNj YWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0MjAgKGMxIGJ5dGVhLCBjMiBieXRlYSwg YzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0 aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQyMSBjYXNjYWRlOyBjcmVhdGUg dGVtcG9yYXJ5IHRhYmxlIHR0MjEgKGMxIGJ5dGVhLCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0 IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAK ZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQyMiBjYXNjYWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRh YmxlIHR0MjIgKGMxIGJ5dGVhLCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBu dW1lcmljKDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBp ZiBleGlzdHMgdHQyMyBjYXNjYWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0MjMgKGMx IGJ5dGVhLCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmljKDcsIDAp LCBjNiBzZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQy NCBjYXNjYWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0MjQgKGMxIGJ5dGVhLCBjMiBi eXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBzZXJpYWw0 ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQyNSBjYXNjYWRlOyBj cmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0MjUgKGMxIGJ5dGVhLCBjMiBieXRlYSwgYzMgYnl0 ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0aG91dCBv aWRzOyAKZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQyNiBjYXNjYWRlOyBjcmVhdGUgdGVtcG9y YXJ5IHRhYmxlIHR0MjYgKGMxIGJ5dGVhLCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVh LCBjNSBudW1lcmljKDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0 YWJsZSBpZiBleGlzdHMgdHQyNyBjYXNjYWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0 MjcgKGMxIGJ5dGVhLCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmlj KDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlz dHMgdHQyOCBjYXNjYWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0MjggKGMxIGJ5dGVh LCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBz ZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQyOSBjYXNj YWRlOyBjcmVhdGUgdGVtcG9yYXJ5IHRhYmxlIHR0MjkgKGMxIGJ5dGVhLCBjMiBieXRlYSwg YzMgYnl0ZWEsIGM0IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0 aG91dCBvaWRzOyAKZHJvcCB0YWJsZSBpZiBleGlzdHMgdHQzMCBjYXNjYWRlOyBjcmVhdGUg dGVtcG9yYXJ5IHRhYmxlIHR0MzAgKGMxIGJ5dGVhLCBjMiBieXRlYSwgYzMgYnl0ZWEsIGM0 IGJ5dGVhLCBjNSBudW1lcmljKDcsIDApLCBjNiBzZXJpYWw0ICkgd2l0aG91dCBvaWRzOyAK --------------0vFEpECx7jrNQMWp17f0L0SK Content-Type: text/x-patch; charset=UTF-8; name="v1-0001-Avoid-deadlock-and-concurrency-during-orphan-temp.patch" Content-Disposition: attachment; filename*0="v1-0001-Avoid-deadlock-and-concurrency-during-orphan-temp.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSA4YTdlOGQ2OGQ2YjMwZTBkMTgwYjIzYTg4ZjFlNDg2NTk0ZjhjYjVmIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBNaWNoYWVsIFpoaWxpbiA8bWl6aGthQEZyZWVCU0Qu b3JnPgpEYXRlOiBTdW4sIDMxIERlYyAyMDIzIDE3OjQ4OjIwICswMzAwClN1YmplY3Q6IFtQ QVRDSCB2MV0gQXZvaWQgZGVhZGxvY2sgYW5kIGNvbmN1cnJlbmN5IGR1cmluZyBvcnBoYW4g dGVtcCB0YWJsZQogcmVtb3ZhbAoKSWYgdGVtcCB0YWJsZXMgY29udGFpbnMgYXV0b2dlbmVy YXRlZCBvYmplY3RzIChmb3IgZXhhbXBsZSwgc2VxdWVuY2VzKSwKdGhlbiBkZWFkbG9jayB3 aXRoIGNsaWVudCB3b3JrZXIgYW5kIGF1dG92YWN1dW0gd29ya2VyIGlzIHBvc3NpYmxlIGF0 CnRoZSBtb21lbnQgb2Ygb3JwaGFuIHRlbXAgdGFibGUgcmVtb3ZhbCBhZnRlciB1bmV4cGVj dGVkIHNlcnZlciByZXN0YXJ0LgoKVGhlIGZpeCBpZGVhIGlzIHRvIGF2b2lkIGNvbmN1cnJl bmN5IGJ5IGNvbmRpdGlvbmFsIGxvY2tpbmcgb2YgbmFtZXNwYWNlCmluIGF1dG92YWN1dW0g d29ya2VyLgotLS0KIHNyYy9iYWNrZW5kL3Bvc3RtYXN0ZXIvYXV0b3ZhY3V1bS5jIHwgMjAg KysrKysrKysrKysrKysrCiBzcmMvYmFja2VuZC9zdG9yYWdlL2xtZ3IvbG1nci5jICAgICB8 IDM4ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiBzcmMvaW5jbHVkZS9zdG9yYWdl L2xtZ3IuaCAgICAgICAgICB8ICAyICsrCiAzIGZpbGVzIGNoYW5nZWQsIDYwIGluc2VydGlv bnMoKykKCmRpZmYgLS1naXQgYS9zcmMvYmFja2VuZC9wb3N0bWFzdGVyL2F1dG92YWN1dW0u YyBiL3NyYy9iYWNrZW5kL3Bvc3RtYXN0ZXIvYXV0b3ZhY3V1bS5jCmluZGV4IDYwMTgzNGQ0 YjRlLi4zMjRiYjMwYTQwNCAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvcG9zdG1hc3Rlci9h dXRvdmFjdXVtLmMKKysrIGIvc3JjL2JhY2tlbmQvcG9zdG1hc3Rlci9hdXRvdmFjdXVtLmMK QEAgLTc2LDYgKzc2LDcgQEAKICNpbmNsdWRlICJjYXRhbG9nL2RlcGVuZGVuY3kuaCIKICNp bmNsdWRlICJjYXRhbG9nL25hbWVzcGFjZS5oIgogI2luY2x1ZGUgImNhdGFsb2cvcGdfZGF0 YWJhc2UuaCIKKyNpbmNsdWRlICJjYXRhbG9nL3BnX25hbWVzcGFjZS5oIgogI2luY2x1ZGUg ImNvbW1hbmRzL2RiY29tbWFuZHMuaCIKICNpbmNsdWRlICJjb21tYW5kcy92YWN1dW0uaCIK ICNpbmNsdWRlICJsaWIvaWxpc3QuaCIKQEAgLTIyNjEsNiArMjI2MiwxOSBAQCBkb19hdXRv dmFjdXVtKHZvaWQpCiAJCQljb250aW51ZTsKIAkJfQogCisJCS8qCisJCSAqIFRyeSB0byBs b2NrIHRoZSB0YWJsZSBuYW1lc3BhY2UuICBBcyBleHBsYWluZWQgYWJvdmUsIHdlIHRyeSB0 byBhdm9pZAorCQkgKiBjb25jdXJyZW5jeSBvbiB0YWJsZSByZW1vdmFscy4gSWYgYmFja2Vu ZCBvciBhbm90aGVyIGF1dG92YWN1dW0KKwkJICogd29ya2VyIHRyaWVzIHRvIGRyb3Agb3Jw aGFuIHRlbXAgdGFibGVzLCBsZXQgaXQgZG8gaXRzIGpvYi4KKwkJICovCisJCWlmICghQ29u ZGl0aW9uYWxMb2NrRGF0YWJhc2VPYmplY3QoTmFtZXNwYWNlUmVsYXRpb25JZCwKKwkJCQkJ CQkJCQkgICBjbGFzc0Zvcm0tPnJlbG5hbWVzcGFjZSwgMCwKKwkJCQkJCQkJCQkgICBBY2Nl c3NTaGFyZUxvY2spKQorCQl7CisJCQlVbmxvY2tSZWxhdGlvbk9pZChyZWxpZCwgQWNjZXNz RXhjbHVzaXZlTG9jayk7CisJCQljb250aW51ZTsKKwkJfQorCiAJCS8qIE9LLCBsZXQncyBk ZWxldGUgaXQgKi8KIAkJZXJlcG9ydChMT0csCiAJCQkJKGVycm1zZygiYXV0b3ZhY3V1bTog ZHJvcHBpbmcgb3JwaGFuIHRlbXAgdGFibGUgXCIlcy4lcy4lc1wiIiwKQEAgLTIyODcsNiAr MjMwMSwxMiBAQCBkb19hdXRvdmFjdXVtKHZvaWQpCiAJCU1lbW9yeUNvbnRleHRTd2l0Y2hU byhBdXRvdmFjTWVtQ3h0KTsKIAl9CiAKKwlpZiAob3JwaGFuX29pZHMgIT0gTklMKSB7CisJ CWVyZXBvcnQoTE9HLAorCQkJCShlcnJtc2coImF1dG92YWN1dW06IGRyb3BwaW5nIG9ycGhh biB0ZW1wIHRhYmxlcyBjb21wbGV0ZWQiKSkpOworCX0KKworCiAJLyoKIAkgKiBDcmVhdGUg YSBidWZmZXIgYWNjZXNzIHN0cmF0ZWd5IG9iamVjdCBmb3IgVkFDVVVNIHRvIHVzZS4gIFdl IHdhbnQgdG8KIAkgKiB1c2UgdGhlIHNhbWUgb25lIGFjcm9zcyBhbGwgdGhlIHZhY3V1bSBv cGVyYXRpb25zIHdlIHBlcmZvcm0sIHNpbmNlIHRoZQpkaWZmIC0tZ2l0IGEvc3JjL2JhY2tl bmQvc3RvcmFnZS9sbWdyL2xtZ3IuYyBiL3NyYy9iYWNrZW5kL3N0b3JhZ2UvbG1nci9sbWdy LmMKaW5kZXggMTA0MzA2OGJhYzcuLjBhYTY2MzM0NmE0IDEwMDY0NAotLS0gYS9zcmMvYmFj a2VuZC9zdG9yYWdlL2xtZ3IvbG1nci5jCisrKyBiL3NyYy9iYWNrZW5kL3N0b3JhZ2UvbG1n ci9sbWdyLmMKQEAgLTEwMTksNiArMTAxOSw0NCBAQCBMb2NrRGF0YWJhc2VPYmplY3QoT2lk IGNsYXNzaWQsIE9pZCBvYmppZCwgdWludDE2IG9ianN1YmlkLAogCUFjY2VwdEludmFsaWRh dGlvbk1lc3NhZ2VzKCk7CiB9CiAKKy8qCisgKgkJQ29uZGl0aW9uYWxMb2NrRGF0YWJhc2VP YmplY3QKKyAqCisgKiBBcyBhYm92ZSwgYnV0IG9ubHkgbG9jayBpZiB3ZSBjYW4gZ2V0IHRo ZSBsb2NrIHdpdGhvdXQgYmxvY2tpbmcuCisgKiBSZXR1cm5zIHRydWUgaWZmIHRoZSBsb2Nr IHdhcyBhY3F1aXJlZC4KKyAqLworYm9vbAorQ29uZGl0aW9uYWxMb2NrRGF0YWJhc2VPYmpl Y3QoT2lkIGNsYXNzaWQsIE9pZCBvYmppZCwgdWludDE2IG9ianN1YmlkLAorCQkgICBMT0NL TU9ERSBsb2NrbW9kZSkKK3sKKwlMT0NLVEFHCQl0YWc7CisJTE9DQUxMT0NLICAqbG9jYWxs b2NrOworCUxvY2tBY3F1aXJlUmVzdWx0IHJlczsKKworCVNFVF9MT0NLVEFHX09CSkVDVCh0 YWcsCisJCQkJCSAgIE15RGF0YWJhc2VJZCwKKwkJCQkJICAgY2xhc3NpZCwKKwkJCQkJICAg b2JqaWQsCisJCQkJCSAgIG9ianN1YmlkKTsKKworCXJlcyA9IExvY2tBY3F1aXJlRXh0ZW5k ZWQoJnRhZywgbG9ja21vZGUsIGZhbHNlLCB0cnVlLCB0cnVlLCAmbG9jYWxsb2NrKTsKKwor CWlmIChyZXMgPT0gTE9DS0FDUVVJUkVfTk9UX0FWQUlMKQorCQlyZXR1cm4gZmFsc2U7CisK KwkvKgorCSAqIE5vdyB0aGF0IHdlIGhhdmUgdGhlIGxvY2ssIGNoZWNrIGZvciBpbnZhbGlk YXRpb24gbWVzc2FnZXM7IHNlZSBub3RlcworCSAqIGluIExvY2tSZWxhdGlvbk9pZC4KKwkg Ki8KKwlpZiAocmVzICE9IExPQ0tBQ1FVSVJFX0FMUkVBRFlfQ0xFQVIpCisJeworCQlBY2Nl cHRJbnZhbGlkYXRpb25NZXNzYWdlcygpOworCQlNYXJrTG9ja0NsZWFyKGxvY2FsbG9jayk7 CisJfQorCisJcmV0dXJuIHRydWU7Cit9CisKIC8qCiAgKgkJVW5sb2NrRGF0YWJhc2VPYmpl Y3QKICAqLwpkaWZmIC0tZ2l0IGEvc3JjL2luY2x1ZGUvc3RvcmFnZS9sbWdyLmggYi9zcmMv aW5jbHVkZS9zdG9yYWdlL2xtZ3IuaAppbmRleCBiZTFkMmM5OWE5NS4uMmMwYzFmMzQ2ZmEg MTAwNjQ0Ci0tLSBhL3NyYy9pbmNsdWRlL3N0b3JhZ2UvbG1nci5oCisrKyBiL3NyYy9pbmNs dWRlL3N0b3JhZ2UvbG1nci5oCkBAIC05Myw2ICs5Myw4IEBAIGV4dGVybiB2b2lkIFNwZWN1 bGF0aXZlSW5zZXJ0aW9uV2FpdChUcmFuc2FjdGlvbklkIHhpZCwgdWludDMyIHRva2VuKTsK IC8qIExvY2sgYSBnZW5lcmFsIG9iamVjdCAob3RoZXIgdGhhbiBhIHJlbGF0aW9uKSBvZiB0 aGUgY3VycmVudCBkYXRhYmFzZSAqLwogZXh0ZXJuIHZvaWQgTG9ja0RhdGFiYXNlT2JqZWN0 KE9pZCBjbGFzc2lkLCBPaWQgb2JqaWQsIHVpbnQxNiBvYmpzdWJpZCwKIAkJCQkJCQkgICBM T0NLTU9ERSBsb2NrbW9kZSk7CitleHRlcm4gYm9vbCBDb25kaXRpb25hbExvY2tEYXRhYmFz ZU9iamVjdChPaWQgY2xhc3NpZCwgT2lkIG9iamlkLAorCQkJCQkJCQkJCSAgdWludDE2IG9i anN1YmlkLCBMT0NLTU9ERSBsb2NrbW9kZSk7CiBleHRlcm4gdm9pZCBVbmxvY2tEYXRhYmFz ZU9iamVjdChPaWQgY2xhc3NpZCwgT2lkIG9iamlkLCB1aW50MTYgb2Jqc3ViaWQsCiAJCQkJ CQkJCSBMT0NLTU9ERSBsb2NrbW9kZSk7CiAKLS0gCjIuNDMuMAoK --------------0vFEpECx7jrNQMWp17f0L0SK--