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 1so4eA-0086RB-CN for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Sep 2024 17:27:23 +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 1so4e9-00Goex-Mc for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Sep 2024 17:27:21 +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 1so4e9-00Goci-DF for pgsql-hackers@lists.postgresql.org; Tue, 10 Sep 2024 17:27:21 +0000 Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1so4e5-000VMf-PH for pgsql-hackers@postgresql.org; Tue, 10 Sep 2024 17:27:20 +0000 Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-718f28f77f4so984677b3a.1 for ; Tue, 10 Sep 2024 10:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; t=1725989237; x=1726594037; darn=postgresql.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=RgUuknEJ2C5xm/ljnP6xojSCxOx1WoIi1psGoXFeVS4=; b=LuW5W+g3e2U4BxRRMHb4hOIlsWC2fJf+f+x3fOMc8d6Dxi4NJscnyf3XSbtAyXXcdT +fLxJsaATtfXlhNpb32pXYKQbQWWes9l/Haj5Oq6VYu0ZUbSFq3/6NclPMYYvelHDq4/ kKjRNVD0I2Ha8BYUD5sS2EXaVt60boKcC4kqY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725989237; x=1726594037; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RgUuknEJ2C5xm/ljnP6xojSCxOx1WoIi1psGoXFeVS4=; b=Uuw4T/6SkrEepp8/ek1e3rWRZqUY/T5urk+6Zd+ykX7a8wf0G+PJHK9za9kbVD5Si1 N7wuLDSr147OY58ouWu0FI04hNOJkNku/8Bz/3yQWYxg4svmNIlHFTRRt6x4KCQN+LXh z63ol+7CRYrszvXVOz6d7JNuSun401iM/w1oKipMWS/sKQ5zoSbWOvRqgqZqPfEBqplV YjdTFX/2RUMyH+cjIZCdU2wui49rPNkxsl1jZIP13WgttUYxWIYLyUSfEJ6QdEDMYfvG 9z51Ehl4CBc+iG5yREWa+9A/vvROfqVPuQnsKqj6xLJNjQsGMX4vMJA4mRSPKEBr0cdW 46cQ== X-Forwarded-Encrypted: i=1; AJvYcCUh9LtYWUq7OSSBIfjk0sgwiPfu8tDyJrxXnEEB1AQ9gI/aASJwa2u88Y4gWee0P2MyTDPOeGFElhpF/MNL@postgresql.org X-Gm-Message-State: AOJu0YzjVncDzQdPQFoWp5sbmGfe/watWpPiBDh6bO0fMAIpMP/jneaT +ltRPBaUVOusX3YJZdhEttfNZTBhOqdS5IdP/A6lf6EbqcWtXzYTqNqxDE+wTQ== X-Google-Smtp-Source: AGHT+IFu1UqdQvKbCvVbD2gdixOmmGKiUJF3Urk7fFRgT5nkYJTbxJmnMS8GNT6noJHb/UuTm4E99w== X-Received: by 2002:a05:6a00:9a1:b0:713:f127:ad5f with SMTP id d2e1a72fcca58-71916e98be4mr234864b3a.22.1725989235437; Tue, 10 Sep 2024 10:27:15 -0700 (PDT) Received: from google.com ([2600:1702:a20:5750::48]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71908fe4de9sm1617760b3a.77.2024.09.10.10.27.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Sep 2024 10:27:14 -0700 (PDT) Date: Tue, 10 Sep 2024 10:27:12 -0700 From: Noah Misch To: Michael Paquier Cc: Jacob Champion , Andrew Dunstan , PostgreSQL Hackers , Euler Taveira Subject: Re: [PATCH] pg_stat_activity: make slow/hanging authentication more visible Message-ID: <20240910172712.e8.nmisch@google.com> References: <20240630174812.d1.nmisch@google.com> <34cc0828-d988-4503-9944-ea6288f0ca8a@dunslane.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.12 (2023-09-09) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Sep 10, 2024 at 02:29:57PM +0900, Michael Paquier wrote: > You are adding twelve event points with only 5 > new wait names. Couldn't it be better to have a one-one mapping > instead, adding twelve entries in wait_event_names.txt? No, I think the patch's level of detail is better. One shouldn't expect the two ldap_simple_bind_s() calls to have different-enough performance characteristics to justify exposing that level of detail to the DBA. ldap_search_s() and InitializeLDAPConnection() differ more, but the DBA mostly just needs to know the scale of their LDAP responsiveness problem. (Someday, it might be good to expose the file:line and/or backtrace associated with a wait, like we do for ereport(). As a way to satisfy rare needs for more detail, I'd prefer that over giving every pgstat_report_wait_start() a different name.)