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 1t98rO-0080kX-1M for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Nov 2024 20:12:05 +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 1t98rK-0022yM-L7 for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Nov 2024 20:12:03 +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 1t98rK-0022yE-AU for pgsql-hackers@lists.postgresql.org; Thu, 07 Nov 2024 20:12:02 +0000 Received: from mail-oi1-x232.google.com ([2607:f8b0:4864:20::232]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t98rG-000jLj-Bv for pgsql-hackers@postgresql.org; Thu, 07 Nov 2024 20:12:01 +0000 Received: by mail-oi1-x232.google.com with SMTP id 5614622812f47-3e6104701ffso962413b6e.0 for ; Thu, 07 Nov 2024 12:11:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1731010317; x=1731615117; darn=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=hueTuFLzPk0glJMZuXSDFk/G5/OmvQhVbHHoLZIMZl0=; b=ct961Ul6LiNlHFuua7TX4+mJQ+bRmhT+M2jOs04D+YVSCiSl2Rqqgfi+SZt3FMMAa4 Yy7dR+4oeO4Ob1g3boNB90SS/em4pp4FGCj6Q8U+pceAnoatgzF2F5gdIY7XiUJlJVfd gryEvHVrGRE9vze9L2SuchSiyZwUHUB+2ewAbHz7uSMuQ0HLVtHpXlv2fmGV8eZT1Jal T/HXkQP6Zkys2JrOcUEXwz/2lqthnHWRkuE4+lrEBVH8ypiKvezZ6AskIyxxUXyFRFg3 rWS0nJ74/YkAnn3rt8QTxa2j/S3dmLDXAFrKJOTMusKcuviCJr3A2lNbHzylx/XOgQCS 1M8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731010317; x=1731615117; 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=hueTuFLzPk0glJMZuXSDFk/G5/OmvQhVbHHoLZIMZl0=; b=kTJNjLJhOnvYh64zT7Hi7KqFdWlLNbLNU0R/ES1F1Seb9myFkKy1kSPzn72kAUSVX5 tOAzy33QfSGeoUDWTm00lPrLqkBPBpVVI2oqD2VM2JRNs31rMfrnuPExT7RWeGs1bx8x H4I0mdySDdtyVUn0hAfxb0Qe8aKtOTFfY++sEQxMgS6JC7rgQCBEITBF3sAlmQx7jbcb OXsD09U4NInA6VFKHRvr+FSyb7Vf14A7DvLF3diwkZWzKKU4ShfuGMTluFL8TSt14KTG E2TvANnBbc5sP8f8fYwpQjYJHv+t0Madn90N8rZ3iIvINCvyEyFEvMh33t9GaMQsaMet X67Q== X-Forwarded-Encrypted: i=1; AJvYcCX6f+Tx4lNzVkVfalugD4puSHkwaVycejj/afNRnmMlhwatkb5OeWzPDbCxuKlbvUTxzvu4/8KsMcjGZ4Rw@postgresql.org X-Gm-Message-State: AOJu0YzSCcULn5GOkXvkgCT9do8KC5LVz9iuVH1eeHLkATN4/WYLNU/P I9+4A7coxY+LfST/vyaOLYka/BWmzv801vTGxKxYfWLfh5wWIsFxVDVt7x1wt0p8DCfuI6pL57D tX7cV4Z00/0zgbEiyJxfmL6KQWmtRrcvwpLAK X-Google-Smtp-Source: AGHT+IFUxfrCoTEw020ktU2aTBQC39zH9IyuYoea6gB5fsONSqvBy69cnfZqc77Kmm6YfPUp4WBr3kAxwFgo5n6vCD8= X-Received: by 2002:a05:6870:5e53:b0:277:e6f6:b383 with SMTP id 586e51a60fabf-295600ee2c1mr254380fac.24.1731010316989; Thu, 07 Nov 2024 12:11:56 -0800 (PST) MIME-Version: 1.0 References: <20240910205850.5d.nmisch@google.com> <20240913145621.43.nmisch@google.com> In-Reply-To: From: Jacob Champion Date: Thu, 7 Nov 2024 12:11:46 -0800 Message-ID: Subject: Re: [PATCH] pg_stat_activity: make slow/hanging authentication more visible To: Andres Freund Cc: Michael Paquier , Robert Haas , Noah Misch , Andrew Dunstan , PostgreSQL Hackers , Euler Taveira 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 Thu, Nov 7, 2024 at 11:41=E2=80=AFAM Andres Freund = wrote: > I think the patch should not be merged as-is. It's just too ugly and frag= ile. Understood; I'm trying to find a way forward, and I'm pointing out that the alternatives I've tried seem to me to be _more_ fragile. Are there any items in this list that you disagree with/are less concerned about? - the pre-auth step must always initialize the entire pgstat struct - two-step initialization requires two PGSTAT_BEGIN_WRITE_ACTIVITY() calls for _every_ backend - two-step initialization requires us to couple against the order that authentication information is being filled in (pre-auth, post-auth, or both) > I think it might make more sense to use pgstat_report_activity() or such = here, > rather than using wait events to describe something that's not a wait. I'm not sure why you're saying these aren't waits. If pam_authenticate is capable of hanging for hours and bringing down a production system, is that not a "wait"? > > I agree that would be amazing! I'm not about to tackle reliable > > interrupts for all of the current blocking auth code for v18, though. > > I'm just trying to make it observable when we do something that > > blocks. > > Well, with that justification we could end up adding wait events for larg= e > swaths of code that might not actually ever wait. If it were hypothetically useful to do so, would that be a problem? I'm trying not to propose things that aren't actually useful. --Jacob