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 1romZd-003KeJ-8u for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Mar 2024 15:49:21 +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 1romZb-005KUg-Qd for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Mar 2024 15:49:20 +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 1romZb-005KTk-H1 for pgsql-hackers@lists.postgresql.org; Mon, 25 Mar 2024 15:49:20 +0000 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1romZU-006MFL-27; Mon, 25 Mar 2024 15:49:18 +0000 Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-56845954ffeso6230701a12.2; Mon, 25 Mar 2024 08:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711381752; x=1711986552; 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=SLk/txEQm2P7fPzsckunLAtFmobwMEAfZ8d8EX+rz64=; b=ZXs/+YMhkjbWY3ZaxYMI45nZJLzPmQIpylBtFMWEbvIWDvoa/EYH0JUyt0w954fufz No+nKwXOjnWcZiA3Pk/v/p20nA4vphTO4MQciagkr1heQf7WfkWSONjJxgJIujh5fePc vfUbAx/5sqmrKqXWooQWGAfMOaaWpIZMTxUubVBuaccoYwQxuQ9qWUZf6rpQZKzVckwP JQL4FlmL/IUERua38B4bVtm53Q3nx9tvjAOZg3dIBeFG1XB30RmvCiRdeHdaelAgy+Pf RyPBaQ562UXg30HFzqQ/hX2iWhVDLvrWTff/fPsVtHaZXgDeX5FUkLE5G+3pCfSyubDv rqLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711381752; x=1711986552; 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=SLk/txEQm2P7fPzsckunLAtFmobwMEAfZ8d8EX+rz64=; b=Sezp8JVQnEZb1Q6CIIM/2EgL+AkuaT6LzJpBUgCdEG+cfOJBci+ayN1M7KjnJW/UX0 himuo7xsAnkcfbKGR2bU4fUF0CZNqTwtU48e8I/7ZQfyBG76WhIThnfZrJ4/wCjyiN2w KGGZSvuMS2/RODAYEpB7xUgvUW2h5txDZ92FQEeY6oZ2PGyRr3lITUixFJNRdTFn1hV1 pK9BzAhCUtbwLhQF72Vw5/0EYo4b2yqTcjPlIfIcUwyOH51wlBjs9l0rTtyw3YsuoTEn puzeA5LSKgg8Vj9bUbvpIbnSon7KBTRY/0FBdliDisBlcJmCiDb9kzRQMuPoO4d4hLdS zY4Q== X-Forwarded-Encrypted: i=1; AJvYcCVsitCkPQMxbCGHi/qTW7BmGTkQJgYTuyodbs42iAy+H87QO49odxFWe4ay0agScIYpRVwzY1VwRbr3RrsEAh1II3gSvLdIUsD3umaJshi8axCWizrTyq72aFUiaOYqi6WLx82K X-Gm-Message-State: AOJu0Yz35ckSAzTeNrRGfYZa2ZWlLhLDKaBA2L0Fwvvm9Qt3boVl2m/Q u7xJvs86Z1zbkJmryNZ0dkdSQtH17YLLyaFqqIKPIaB09LbNeuwscitVFw8O2gqVVNAec8sKJhM oUShJA1TktFV7kGboLBKLY+nnxr8k/EwV X-Google-Smtp-Source: AGHT+IFFw/0rc8d986Ep8F3sCzy/+YiG3iQ3VAQpBngzcoMukRSVE5GMYf2fZAB7TlExLLO8y59G8B1aKCL+6NgcgE4= X-Received: by 2002:a17:907:9484:b0:a47:479a:a12b with SMTP id dm4-20020a170907948400b00a47479aa12bmr5219783ejc.43.1711381751645; Mon, 25 Mar 2024 08:49:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Haas Date: Mon, 25 Mar 2024 11:49:00 -0400 Message-ID: Subject: Re: pgsql: Track last_inactive_time in pg_replication_slots. To: Bertrand Drouvot Cc: Amit Kapila , shveta malik , Bharath Rupireddy , Amit Kapila , "pgsql-hackers@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 Mon, Mar 25, 2024 at 11:16=E2=80=AFAM Bertrand Drouvot wrote: > > IIUC, Bertrand's point was that users can interpret last_active_time > > as a value that gets updated each time they decode a change which is > > not what we are doing. So, this can confuse users. Your expectation of > > answer (NULL) when the slot is active is correct and that is what will > > happen. > > Yeah, and so would be the confusion: why is last_active_time NULL while o= ne is > using the slot? I agree that users could get confused here, but the solution to that shouldn't be to give the field a name that is the opposite of what it actually does. I expect a field called last_inactive_time to tell me the last time that the slot was inactive. Here, it tells me the last time that a currently-inactive slot previously *WAS* active. How can you justify calling that the last *INACTIVE* time? AFAICS, the user who has the confusion that you mention here is simply wrong. If they are looking at a field called "last active time" and the slot is active, then the correct answer is "right now" or "undefined" and that is what they will see. Sure, they might not understand that. But flipping the name of the field on its head cannot be the right way to help them. With the current naming, I expect to have the exact opposite confusion as your hypothetical confused user. I'm going to be looking at a slot that's currently inactive, and it's going to tell me that the last_inactive_time was at some time in the past. And I'm going to say "what the heck is going on here, the slot is inactive *right now*!" Half of me wonders whether we should avoid this whole problem by renaming it to something like last_state_change or last_state_change_time, or maybe just state_change like we do in pg_stat_activity, and making it mean the last time the slot flipped between active and inactive in either direction. I'm not sure if this is better, but unless I'm misunderstanding something, the current situation is terrible. --=20 Robert Haas EDB: http://www.enterprisedb.com