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 1rsKuF-006PFF-25 for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Apr 2024 11:05:19 +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 1rsKuE-0030mt-95 for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Apr 2024 11:05:18 +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 1rsKuD-0030ml-Vr for pgsql-hackers@lists.postgresql.org; Thu, 04 Apr 2024 11:05:17 +0000 Received: from mail-oa1-x2e.google.com ([2001:4860:4864:20::2e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rsKuB-000aUr-Cb for pgsql-hackers@lists.postgresql.org; Thu, 04 Apr 2024 11:05:17 +0000 Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-22e8652090aso487112fac.2 for ; Thu, 04 Apr 2024 04:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712228713; x=1712833513; 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=360NRmj+M1a7dnq9cq/x3gW6roUysrEygy0zBoN9vfA=; b=gzgNs1IW1nLYfCltHnELguYu0pzn13w9IEnjN8vWqc6Gheg/kgFScof3eZJIA6LJq8 anwzpJU8MAm05lSGdL8qmwI/IEZnk2YYguN6BHWPjnCdTelA+gA2cTuLnKiIvSQ4rnjq +zoh2mTtSp/59aqgghPbOT/ONIPkp3H2INn6G/MukcJDmftTnNOYjBUCAaMNcmb0c2En f3Z9doxjwg8n9atvaMEuSkj8o5ghA1lrO+NdD0Kj9EZNmz60Nq2zKmA30cNbWe63BZjM eNDwuHV46PNyC1gOmB5+G1IG/ygKTTStFs9j30AePujri+A1PGsGFuNnMe3taUbtLQJX ACPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712228713; x=1712833513; 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=360NRmj+M1a7dnq9cq/x3gW6roUysrEygy0zBoN9vfA=; b=CSSdfm8yAcIM+hfMayjN9cgrE+WreWt9yk//41iw4PzDpZHo2UZ1V8asMlTfgkzGMZ zAPvuqFsQPdgOEqma+MxqZhZkEXb8GT0uRLmfAfsYl+bWh42JWmswz5tHirg81+hNDvD mS7I9lxVoBInKlW/dIMEsTs5Rfy70TEcTo13UNFY/Mz+UgJ79Nn/DiPX3ghonvWJYjVZ c4WAJ0R1oKadUmo1PG45q0lRlqiTwycvtOR5l30q9J5+L8reUTNE2hqAFgK3PPEZYfq3 ARrzzCZyV+BkvMEU6XdTM0SAH4o7chQNTXLX+FKAP5Z1HSYcjMHDFWEFB7F4CLufqZln BoCw== X-Forwarded-Encrypted: i=1; AJvYcCVsd/d1uPSDX1/qNrd7eiOBcEe6VeBoD/kAnDp5N5Ey3uMZ0NGaDldwFnJlLFEcYUBfiyR+u6pRG+KslkrzHrZRzs/nzEVPEQ5HnVJT2xiSpckp X-Gm-Message-State: AOJu0Yx5M8I0BrI44GbJk+ZGVuu3SN5oVZZn+ilfgKHq5xAtMI6UGrH2 2cls/a5afUD82druS1Ym4dcB6Pzl2UviEuhpEkifAZJQnKgE67yFK28JPm21WvNiKliXRxg0p7h OUpM3O007JSMwCaOIK+Bi4FVsYhM= X-Google-Smtp-Source: AGHT+IFwTwamsl+/gwuneyZxbZBW3YRDaCgUIRUIV3YnQflnEaWyuAOcWaX16PZqaCdxSvy87QDKTiZp2nmi5JH6MuI= X-Received: by 2002:a05:6871:29c:b0:229:f8c1:dd5f with SMTP id i28-20020a056871029c00b00229f8c1dd5fmr2194051oae.48.1712228713308; Thu, 04 Apr 2024 04:05:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Thu, 4 Apr 2024 16:35:01 +0530 Message-ID: Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation To: Bharath Rupireddy Cc: Bertrand Drouvot , shveta malik , Masahiko Sawada , Nathan Bossart , PostgreSQL Hackers 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, Apr 4, 2024 at 11:12=E2=80=AFAM Bharath Rupireddy wrote: > > On Thu, Apr 4, 2024 at 10:48=E2=80=AFAM Amit Kapila wrote: > > > > The v33-0001 looks good to me. I have made minor changes in the > > comments/commit message and removed one part of the test which was a > > bit confusing and didn't seem to add much value. Let me know what you > > think of the attached? > > Thanks for the changes. v34-0001 LGTM. > I was doing a final review before pushing 0001 and found that 'inactive_since' could be set twice during startup after promotion, once while restoring slots and then via ShutDownSlotSync(). The reason is that ShutDownSlotSync() will be invoked in normal startup on primary though it won't do anything apart from setting inactive_since if we have synced slots. I think you need to check 'StandbyMode' in update_synced_slots_inactive_since() and return if the same is not set. We can't use 'InRecovery' flag as that will be set even during crash recovery. Can you please test this once unless you don't agree with the above theory? --=20 With Regards, Amit Kapila.