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 1tGfEQ-003ycB-J9 for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Nov 2024 14:10: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 1tGfEO-005Hca-ES for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Nov 2024 14:10:56 +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 1tGfEO-005HcS-0D for pgsql-hackers@lists.postgresql.org; Thu, 28 Nov 2024 14:10:56 +0000 Received: from mail-yb1-xb34.google.com ([2607:f8b0:4864:20::b34]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tGfEK-004LYd-Nr for pgsql-hackers@lists.postgresql.org; Thu, 28 Nov 2024 14:10:54 +0000 Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-e3978c00a5aso571628276.1 for ; Thu, 28 Nov 2024 06:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732803051; x=1733407851; 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=y1KuRmaOAkO8qA+WVB1r4fv0wEoLb+MfiRt56Oar0+0=; b=SowcEJ/eA0UFHxL9lx0EY2/rdjUxgg4z4WFrLhg4TEymO5CEJ1vFtRGDolgsZsH4Gi mMsGxr0WzIUw2cTNBZyFQewRWva+gkKfsqbssbeIMBo/mnbowmx+eO+qB8H1em3acvMY k3IfXYjRERM+XjojfhwMntvWbrolLINY0EiFft3aYVADiec/1N/jOtthI5VFt3ToEnMt T//Ijx+j2K7YQ5FBZfWGPplDLmjZlOgSspp3dD9k9laNX1cGH464AJJVf13puZcu7gmq gu464GqeqJqaLbLlM5vqiM4XMPBUX4cB70/GkhYdtcXFmTaWweReo4+/VBZtKH+oCdRP kU/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732803051; x=1733407851; 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=y1KuRmaOAkO8qA+WVB1r4fv0wEoLb+MfiRt56Oar0+0=; b=QFf1CN5wi8ojTLh2WmY54Nr89Q46D763Sq7LBpLcUoCh0uAtF85R5NuT3Wd/uBrBH3 UAGU/WP008oa85su4wf9v/aauyrQUv1Ze3JC24wAUXlrff/UnL4QVqDrcLk4Cn341HBK DVJSGGdAbyP2A/F691lmDSqnWQrXnmyXqdqElMCNgbyY3gTGQeCMF/vMJGgK5lxIRAU3 TI+j87vk97Ec7tgbrkvtX4f/4Ib9q4VLou4dXc9DZeFg+qhgsERyGNwYUqdqiDkzwoxV I4DiybOYr2yGjiA4Dx7gjziInb+Tplu+6AHVAV2ikHJKVSePCaaWTdfW0Hkmty8A/ya0 vrig== X-Forwarded-Encrypted: i=1; AJvYcCX6jkG2lQ9gzlaaQa46Zxslf9kWLGB7qPfWOeG0aHI/Dj0GrYtFaG2e5JckYfquNtPl71Lz0cIrXXixmDOg@lists.postgresql.org X-Gm-Message-State: AOJu0Yzlc9CbDivnP6V38Dch77pG+AA06zk51jAu/GK/Rwja6Q0i1sJe dSGJZDpIRqLXyTFKuQnGRVtQXia5yrXvpcOPgmo23XfHqSV0e2gAUEwPfUdTfsfehbRyod1Q51D uKaE0dYohTDSt/Kb1xqEyfL9uq+LFNpqcfcA= X-Gm-Gg: ASbGncvffPY+ugrZ5X4u0Ws+FfNVdKnbEdNFz6wVYhh5AW419f7iueYpKj//VEzRHyY ooVJdYAHFINg5w13UhQlrc+aygYMHkg== X-Google-Smtp-Source: AGHT+IG3zpffEG/Tb2GyaIw/mZ+SC09/WZ80XHbH0JH3eqquk4+KZpZzPm85W/X8NzL0iDbAbN//MALXGYpLInySnMM= X-Received: by 2002:a05:6902:2786:b0:e39:774f:b28d with SMTP id 3f1490d57ef6-e39774fb5c6mr2203305276.41.1732803051046; Thu, 28 Nov 2024 06:10:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: vignesh C Date: Thu, 28 Nov 2024 19:40:32 +0530 Message-ID: Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation To: Nisha Moond Cc: Peter Smith , shveta malik , Bharath Rupireddy , Amit Kapila , Ajin Cherian , Bertrand Drouvot , 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 Wed, 27 Nov 2024 at 16:25, Nisha Moond wrote: > > On Wed, Nov 27, 2024 at 8:39=E2=80=AFAM Peter Smith wrote: > > > > Hi Nisha, > > > > Here are some review comments for the patch v50-0002. > > > > =3D=3D=3D=3D=3D=3D > > src/backend/replication/slot.c > > > > InvalidatePossiblyObsoleteSlot: > > > > 1. > > + if (now && > > + TimestampDifferenceExceeds(s->inactive_since, now, > > + replication_slot_inactive_timeout_sec * 1000)) > > > > Previously this was using an additional call to SlotInactiveTimeoutChec= kAllowed: > > > > + if (SlotInactiveTimeoutCheckAllowed(s) && > > + TimestampDifferenceExceeds(s->inactive_since, now, > > + replication_slot_inactive_timeout * 1000)) > > > > Is it OK to skip that call? e.g. can the slot fields possibly change > > between assigning the 'now' and acquiring the mutex? If not, then the > > current code is fine. The only reason for asking is because it is > > slightly suspicious that it was not done this "easy" way in the first > > place. > > > Good catch! While the mutex was being acquired right after the now > assignment, there was a rare chance of another process modifying the > slot in the meantime. So, I reverted the change in v51. To optimize > the SlotInactiveTimeoutCheckAllowed() call, it's sufficient to check > it here instead of during the 'now' assignment. > > Attached v51 patch-set addressing all comments in [1] and [2]. Few comments: 1) replication_slot_inactive_timeout can be mentioned in logical replication config, we could mention something like: Logical replication slot is also affected by replication_slot_inactive_time= out 2.a) Is this change applicable only for inactive timeout or it is applicable to others like wal removed, wal level etc also? If it is applicable to all of them we could move this to the first patch and update the commit message: + * If the slot can be acquired, do so and mark it as invalidated. If + * the slot is already ours, mark it as invalidated. Otherwise, we'll + * signal the owning process below and retry. */ - if (active_pid =3D=3D 0) + if (active_pid =3D=3D 0 || + (MyReplicationSlot =3D=3D s && + active_pid =3D=3D MyProcPid)) 2.b) Also this MyReplicationSlot and active_pid check can be in same line: + (MyReplicationSlot =3D=3D s && + active_pid =3D=3D MyProcPid)) 3) Error detail should start in upper case here similar to how others are d= one: + case RS_INVAL_INACTIVE_TIMEOUT: + appendStringInfo(&err_detail, _("inactivity exceeded the time limit set by \"%s\"."), + "replication_slot_inactive_timeout"); + break; 4) Since this change is not related to this patch, we can move this to the first patch and update the commit message: --- a/src/backend/replication/logical/slotsync.c +++ b/src/backend/replication/logical/slotsync.c @@ -1508,7 +1508,7 @@ ReplSlotSyncWorkerMain(char *startup_data, size_t startup_data_len) static void update_synced_slots_inactive_since(void) { - TimestampTz now =3D 0; + TimestampTz now; /* * We need to update inactive_since only when we are promoting standby to @@ -1523,6 +1523,9 @@ update_synced_slots_inactive_since(void) /* The slot sync worker or SQL function mustn't be running by now *= / Assert((SlotSyncCtx->pid =3D=3D InvalidPid) && !SlotSyncCtx->syncin= g); + /* Use same inactive_since time for all slots */ + now =3D GetCurrentTimestamp(); 5) Since this change is not related to this patch, we can move this to the first patch. @@ -2250,6 +2350,7 @@ RestoreSlotFromDisk(const char *name) bool restored =3D false; int readBytes; pg_crc32c checksum; + TimestampTz now; /* no need to lock here, no concurrent access allowed yet */ @@ -2410,6 +2511,9 @@ RestoreSlotFromDisk(const char *name) NameStr(cp.slotdata.name)), errhint("Change \"wal_level\" to be \"replica\" or higher."))); + /* Use same inactive_since time for all slots */ + now =3D GetCurrentTimestamp(); + /* nothing can be active yet, don't lock anything */ for (i =3D 0; i < max_replication_slots; i++) { @@ -2440,9 +2544,11 @@ RestoreSlotFromDisk(const char *name) /* * Set the time since the slot has become inactive after loading the * slot from the disk into memory. Whoever acquires the slot i.e. - * makes the slot active will reset it. + * makes the slot active will reset it. Avoid calling + * ReplicationSlotSetInactiveSince() here, as it will not set the time + * for invalid slots. */ - slot->inactive_since =3D GetCurrentTimestamp(); + slot->inactive_since =3D now; [1] - https://www.postgresql.org/docs/current/logical-replication-config.ht= ml Regards, Vignesh