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 1uFTwP-004wGi-Nm for pgsql-performance@arkaria.postgresql.org; Thu, 15 May 2025 08:27:46 +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 1uFTwO-00D3lR-Nx for pgsql-performance@arkaria.postgresql.org; Thu, 15 May 2025 08:27:44 +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 1uFTwO-00D3lI-E0 for pgsql-performance@lists.postgresql.org; Thu, 15 May 2025 08:27:44 +0000 Received: from mail-yb1-xb2b.google.com ([2607:f8b0:4864:20::b2b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uFTwL-001tPI-30 for pgsql-performance@lists.postgresql.org; Thu, 15 May 2025 08:27:43 +0000 Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-e7ab544d5efso603336276.3 for ; Thu, 15 May 2025 01:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747297661; x=1747902461; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=18VyS5dESJLfKlH6vh6YcNMm3pPDjvLjjdKZz94dsuQ=; b=lwEU1sRLXkBlzew4VgYlGuC4611GNrF3KnEisr/yZ6xmon5UUVWSptR4T38SOq8EdF l9FKnGTB9gKZd6ywWVbnWjal5QDGXmp4agfnTv7BH7MjiFtTIwxJAwD5MNjJFNHJTE1W yV5PLgChQb7OAaivqWET9kfxFcG6ZcyKWu7ek/ePQ+U3jSFUx8cFDd/sPj9UF/d2GBNl L3UvK6ShvY8M9CmYXOkPK/NMusJcm9hqu7Pry6sl5/JxD5lC/TLivJRIpoG7aQWD7TZf TPES4nh/+GctF8KFkXNXx3DqnpgRklm2tGNJz82n/TlXyQCW5e2P1jxk+SPc9Tpqo0+p EEjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747297661; x=1747902461; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=18VyS5dESJLfKlH6vh6YcNMm3pPDjvLjjdKZz94dsuQ=; b=rkWFf+P43wNltG15pzy+64QVW/Pxj6R1jBBLjUz45ixR8WCSNL8pFLYbsuacGPFB/D 2VUWQeLynLtD9W4EPUaWhXj67oo/oBWAp/5jt17h8UP3H9ZgFwJDv8l1SunCxqy6A5UC Sq6puzqoPiaWkB5eimcYrsRKpO3f6bSbIdd3/3SuwLc4v63g5KWpno2tFQGfDb9qGkNq qmFlRdWbov/HLZ2nKS1IN3XbHd7COVD6l8hwAEnMWaK84AWg88K2W4Mp4TxtCQzKfi84 mr1D+VraW+/wF3w6s9+nA50pcq18f8wRgC7apNDrkzCsAwFEOJnubk71EXLboSEU/73i K8mg== X-Gm-Message-State: AOJu0YxLEW3V2Q+cQZe3lLTSXoKV9o6lCU2PeONn6KrH25xUnykV7b5A ATuh8jsAltemcSBfgD/PdYIZjtDhKn4shfQKzcQ+qSqG9+mHMFF9SJX+N12sxGqXBWAhEatZy8V I7RxVSH88VthboD4h46Pmu05vmPyJC9vq X-Gm-Gg: ASbGncu6OPzmpzix+yFMAn1O2PlaaVXJmMbejbmmvd/Yh3GvRPxV0WOEbp4MAt8BPdn jtGA4OQf2upvN/8K1N51f51rQXRzeyHyU1iDsi+tbcKUI+5NZ3A2+fiBi3QOpvB/eULxaounOg+ +2nelHmKdaLeR6kr9/kyOUnyjd9eWpQ0oOxpn5S+1RjoTJ X-Google-Smtp-Source: AGHT+IFfpeDE1aLD3hW/5ndhtBewvDmkMN7SsNkKYNlWhIGsgeigHFYItwslnRehZtYW/jYqitlQvSx5jpp8Cq588zY= X-Received: by 2002:a05:6902:248b:b0:e79:330e:51a2 with SMTP id 3f1490d57ef6-e7b3d598835mr7832411276.30.1747297661458; Thu, 15 May 2025 01:27:41 -0700 (PDT) MIME-Version: 1.0 From: James Pang Date: Thu, 15 May 2025 16:27:31 +0800 X-Gm-Features: AX0GCFujaMmWHqJIVhg7EIVbuetUrU_e-_0fekHg-jCtACC5TfXIP11kxtGVSNc Message-ID: Subject: a lot of session wait on lock relation To: pgsql-performance@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000006da4be0635287070" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000006da4be0635287070 Content-Type: text/plain; charset="UTF-8" Hi, PGv 15.10, many session coming in doing "insert into tablexxx values...." in parallel, this is a range partition tables, total 12 partitions plus one default partition, only three btree indexes, no others constraints ,no foreign key. but we see hundreds of session waiting on "lock:relation", why inserts into partition table cause "relation lock" ? Thanks, James --0000000000006da4be0635287070 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
=C2=A0 =C2=A0PGv 15.10,=C2=A0 many session coming = in doing "insert into tablexxx values...." in parallel, this is a= range partition tables, total 12 partitions plus one default partition, on= ly three btree indexes, no others constraints ,no foreign key. but we see h= undreds=C2=A0of session waiting on "lock:relation", why inserts i= nto partition table cause "relation lock" ?=C2=A0

<= /div>
Thanks,

James
--0000000000006da4be0635287070--