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 1sJuIb-007HY9-Gb for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Jun 2024 12:20:25 +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 1sJuIY-00FbEM-Uo for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Jun 2024 12:20:23 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sJuIY-00FbAp-K3 for pgsql-hackers@lists.postgresql.org; Wed, 19 Jun 2024 12:20:23 +0000 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sJuIX-002SDY-0X for pgsql-hackers@lists.postgresql.org; Wed, 19 Jun 2024 12:20:22 +0000 Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-57c68682d1aso7526983a12.3 for ; Wed, 19 Jun 2024 05:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718799619; x=1719404419; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=7PcMFTNz9RSipfJfQ2hkjv3g8yi85CY4NkhBmsHnaeo=; b=FjwL/6aQizx3tH3LyvP7ZcUgb5jZSdnOzAmq/iCD6cAiedbWxaO91xBxRcpI6S+l0U 45FUt5bf37JSel5XC4F6cu/w2hU2U+VTYqmnU/Or+vF8RqNZSfCGHvuugf6euN1asPuH q1e0EuK9ilmglLaBIOe2oshPKsref6agZFFLtIf8ezO9lVWDe03qUL+Xhwa3mcJhPUpu qj0QNoMvh8TWrkbHNj9W32v/ZnEvsYEaXPzd4Vze/A9anL+zEIgDdwVCcwM5HB9pdBNP wvYPg16UIteKdiGstv2+j6FbDeIMaqip3r2nThTf1OCSqjy6sqmq0YEaI2OGQ/Fb83cH bc7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718799619; x=1719404419; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7PcMFTNz9RSipfJfQ2hkjv3g8yi85CY4NkhBmsHnaeo=; b=NKZFcrpMTRBCALGd9voA/GrcndFQ5p2t+0o4UVOfGrVoSe1/uhC8fXYe70lD27nct4 a4mZ1RitRUQGm1WrbDFD2Q775Qe2yDCMQkYB9redK343wDq4DyZClpCkmC1nD5e44Kq0 w2aeT0DWqG27TjjaVV3zUBiZt93dkT1N9L8Yv6o4N3IkHAbZSJx96wUlaruLrxcRag5I DaU4GErUu7wmD8JCEtA6GdZV7AZK3aZTJGTb2KwXeyQi4qYLxVE7FKq0BDlme7/g4m69 BGoLPHzdPBSy25W0npLpaHWeREgdC7IE/EK6RHBgrp2YY2AQVMzcgaq53YQ1BH6BO1rK Zkuw== X-Gm-Message-State: AOJu0YydBys19aHCGYgyfBelfnnfu3oy1ZNUHKHdZ/Z5HeK3pkapOCNy yJ2uMXUpoNY8fPOwGi+DdtorsxQxBSEvBq1QUbLQevqlUBCOrf0ysB/G0HSxGGRqfha5Q9qgQpj ofxVTDIhe3PU2xB/WS9hHLTkVoKJhFw== X-Google-Smtp-Source: AGHT+IH8b+9hLvUgiPBvqBMzHW4G3esdVcFX1YiUOv1OQGswFM/iMuMlXe5EoPwG4QKmibe/eR80n7HcehZW/UWHgFg= X-Received: by 2002:a17:907:c70f:b0:a6f:b1a8:e43 with SMTP id a640c23a62f3a-a6fb1a81d77mr91026966b.16.1718799619173; Wed, 19 Jun 2024 05:20:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Haas Date: Wed, 19 Jun 2024 08:20:08 -0400 Message-ID: Subject: Re: Avoid orphaned objects dependencies, take 3 To: Ashutosh Sharma Cc: pgsql-hackers@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jun 19, 2024 at 7:49=E2=80=AFAM Ashutosh Sharma wrote: > If the dependency is more, this can hit max_locks_per_transaction > limit very fast. Your experiment doesn't support this conclusion. Very few users would have 15 separate user-defined types in the same table, and even if they did, and dropped the table, using 23 locks is no big deal. By default, max_locks_per_transaction is 64, so the user would need to have more like 45 separate user-defined types in the same table in order to use more than 64 locks. So, yes, it is possible that if every backend in the system were simultaneously trying to drop a table and all of those tables had an average of at least 45 or so user-defined types, all different from each other, you might run out of lock table space. But probably nobody will ever do that in real life, and if they did, they could just raise max_locks_per_transaction. When posting about potential problems like this, it is a good idea to first do a careful thought experiment to assess how realistic the problem is. I would consider an issue like this serious if there were a realistic scenario under which a small number of backends could exhaust the lock table for the whole system, but I think you can see that this isn't the case here. Even your original scenario is more extreme than what most people are likely to hit in real life, and it only uses 23 locks. --=20 Robert Haas EDB: http://www.enterprisedb.com