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 1sl0yj-004VBe-Pb for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Sep 2024 06:55:58 +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 1sl0yg-0099d3-RW for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Sep 2024 06:55:55 +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 1sl0yg-0099cv-GE for pgsql-hackers@lists.postgresql.org; Mon, 02 Sep 2024 06:55:54 +0000 Received: from mail-oa1-x30.google.com ([2001:4860:4864:20::30]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sl0yZ-000FSg-Nz for pgsql-hackers@lists.postgresql.org; Mon, 02 Sep 2024 06:55:53 +0000 Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-277e4327c99so611286fac.0 for ; Sun, 01 Sep 2024 23:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725260147; x=1725864947; 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=E/sDxW8NWV382R6fqbraYHW9GZG47ciwloQUyEN1QhI=; b=TCMkdA/o2SxRcuge4d1SlTx6q+6LzMycy6B4l3UdAAsEmghL9cmTpWSowEwPj1SIAA M29Rb3d4QJ6Lal7274MVst3V44+mnPsMgL67EMiChqtwQw8ZKeVmWSTW+g9UpUmLKsC9 vurt2E+NRnI4vc9UUB7JGQFZrEF8TkXixibwHQCM+PY4VzVn9okLqt8t4Tokb+UuXBdc v3k0OcTMdX1W7zdVSZBy1fP02SpNK5LhNZTFmpp+NZuI84P3lKQCgy46dQXwQPjHFi6D tCXnqIZA4tMOWaOdY37gwP5J57HNiNDJI9H8sz4xDUebSIGf7Okuj2xan6S6oRzck+ci DDlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725260147; x=1725864947; 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=E/sDxW8NWV382R6fqbraYHW9GZG47ciwloQUyEN1QhI=; b=R38kHY5yKskiosY3eKCIH9F3F5nXObOJmLIB6C1uXILsDYWTaVnlzfSu+4Cy4Vqi8b AHcrDz8hzzeSDP/HgVlFlouoodvKwxYPDM+EfyC20fPrAeNG+gzgNGwyI9Nl9ZnYL6Ws b8pmOBkrR0trNh198z/WhI8aVY1FwnS7CWaJQjd2Ii7T/6Dh6Nj1002PHgKiFJIVZGE7 pbma7jXA7puXtzL+HEDMWWstOHXPRkf78xofVVTh64rLPG3sanZE+eby8cEJYxNH1jOa SGqDoXpzcUn/Sy/IO8ZMsdIEP9aGTDiH1lURTQ/mPkybvnIxRR4zHL7rDBFRQ7bNzP0F FyLg== X-Forwarded-Encrypted: i=1; AJvYcCUU/oiSi0122rvReAb3tXuWWbTielHYQkotgIigapIHHhazNpWVVNXvZDGnP6zPoGCpcr5Vx5yqUE3Lgj6c@lists.postgresql.org X-Gm-Message-State: AOJu0YwO9ymjQjs2rZMJ4cfeOhJ2XjoDhYWHeXW/a0D04bxRWcCITlcp JSgjitD/I/HpDQmuJDGZ84Ulhw3LsM1R6Ze4E3KIOXNv19PpQxk5+6A0NleRwkk9dWJDCJHsGIZ mYsPQvPvVuXvVhp3gXDFv89vaygA= X-Google-Smtp-Source: AGHT+IEzQdj3GvhRijIV9lCgjsjvhLdEf5veqrOeEp3Zn2qeDGAXhTdJyJD1xudKC0ZB2mYd3WbSqPTD8VtNl1F7v1Y= X-Received: by 2002:a05:6870:1b8c:b0:254:994b:5e6b with SMTP id 586e51a60fabf-277d06c6606mr7707890fac.44.1725260146683; Sun, 01 Sep 2024 23:55:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Mon, 2 Sep 2024 12:25:35 +0530 Message-ID: Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation To: Bharath Rupireddy Cc: Ajin Cherian , 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, Aug 29, 2024 at 11:31=E2=80=AFAM Bharath Rupireddy wrote: > > Thanks for looking into this. > > On Mon, Aug 26, 2024 at 4:35=E2=80=AFPM Amit Kapila wrote: > > > > Few comments on 0001: > > 1. > > @@ -651,6 +651,13 @@ synchronize_one_slot(RemoteSlot *remote_slot, Oid > > > > + /* > > + * Skip the sync if the local slot is already invalidated. We do this > > + * beforehand to avoid slot acquire and release. > > + */ > > > > I was wondering why you have added this new check as part of this > > patch. If you see the following comments in the related code, you will > > know why we haven't done this previously. > > Removed. Can deal with optimization separately. > > > 2. > > + */ > > + InvalidateObsoleteReplicationSlots(RS_INVAL_INACTIVE_TIMEOUT, > > + 0, InvalidOid, InvalidTransactionId); > > > > Why do we want to call this for shutdown case (when is_shutdown is > > true)? I understand trying to invalidate slots during regular > > checkpoint but not sure if we need it at the time of shutdown. > > Changed it to invalidate only for non-shutdown checkpoints. inactive_time= out invalidation isn't critical for shutdown unlike wal_removed which can h= elp shutdown by freeing up some disk space. > > > The > > other point is can we try to check the performance impact with 100s of > > slots as mentioned in the code comments? > > I first checked how much does the wal_removed invalidation check add to t= he checkpoint (see 2nd and 3rd column). I then checked how much inactive_ti= meout invalidation check adds to the checkpoint (see 4th column), it is not= more than wal_remove invalidation check. I then checked how much the wal_r= emoved invalidation check adds for replication slots that have already been= invalidated due to inactive_timeout (see 5th column), looks like not much. > > | # of slots | HEAD (no invalidation) ms | HEAD (wal_removed) ms | PATCHE= D (inactive_timeout) ms | PATCHED (inactive_timeout+wal_removed) ms | > |------------|----------------------------|-----------------------|------= -------------------------|------------------------------------------| > | 100 | 18.591 | 370.586 | 359.2= 99 | 373.882 | > | 1000 | 15.722 | 4834.901 | 5081.= 751 | 5072.128 | > | 10000 | 19.261 | 59801.062 | 61270= .406 | 60270.099 | > > Having said that, I'm okay to implement the optimization specified. Thoug= hts? > The other possibility is to try invalidating due to timeout along with wal_removed case during checkpoint. The idea is that if the slot can be invalidated due to WAL then fine, otherwise check if it can be invalidated due to timeout. This can avoid looping the slots and doing similar work multiple times during the checkpoint. --=20 With Regards, Amit Kapila.