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.96) (envelope-from ) id 1wQJ69-001QV4-0g for pgsql-hackers@arkaria.postgresql.org; Fri, 22 May 2026 06:11:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wQJ66-00CTrR-1z for pgsql-hackers@arkaria.postgresql.org; Fri, 22 May 2026 06:11: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.96) (envelope-from ) id 1wQJ66-00CTrI-0x for pgsql-hackers@lists.postgresql.org; Fri, 22 May 2026 06:11:03 +0000 Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wQJ64-00000000qf0-1y3E for pgsql-hackers@postgresql.org; Fri, 22 May 2026 06:11:02 +0000 Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-36622412e97so5040598a91.2 for ; Thu, 21 May 2026 23:10:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779430258; cv=none; d=google.com; s=arc-20240605; b=BWyb3qDcJtHKT8+I6k+7YsOgajLxAH1yM621rFq6tsa9HD4Rop4359WF5yBBk5gWky z9rN6YZd0ESdXd47bIYNQJHWKbiEWtpMUytoRfbB8g5SaWKTPBDku5VsUzGYRA7XTLHw b6o69LwLmC2HNW8dwBKup9oL1GbiYzN+8PN06hTLfZcNYIrqGp33sFM3E6SVyu+1850V oQnRAEMt+cSB551jSLMWCuIt2I322LTD6xogkzfcBKZXIucYhRI3RuqbR3Dd45Skg4/D i7desyBz4G24T652jEtRmLWAhjFMP+2IfFWA0iusc1nxtzAtqqnYfcXmfXCSHeH0ocgq sgVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ojcm6DVwDWABigVdQRXek9ypyb+6SWXapWuLW2WONAI=; fh=Lzx7wtg4s234Gvyfocdqo5lml4SbGBcx2vLZYMlP1So=; b=TTfMjo8UXj7dE0DB5sjZcHY9LYBC+HcNRaiGMmkaDJEFRxjd+4wN7DML18GwBOBI4T RmyAVVgzQmMq6ZCBpszrSAsaFy3OTtD3uwtVvhHTh2REaTUd2hWRHfwRiQa/+8B22rbV onscPc3qVlcCBX7zTCnGXB+qTPrhtig2O/WLdrcW7n/Mbe3fZAiFkHHzyjmk6YPRrQvW LQ3OE6yOXMlFrNtyEyltlIcE9vQwErxf+ugkmBH0fy27+S4bNJzS2XkjdWYWbknFmcdK AIYFQ0QIbi44CFgkkkGpmsBGG8Y9VjtPATFyeR7dORrVTrfN+bD5WeEknHVc1gxqKV5e GJ4w==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779430258; x=1780035058; 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=ojcm6DVwDWABigVdQRXek9ypyb+6SWXapWuLW2WONAI=; b=NAvpAxvJ/aI8KtqFIvijFoomcTfHGPkKflt2zISyiyLJ82b55UD1OiYSrZi8JnV9Pu aDTu/lsb7VDvQfmGBJJnDCDmlAMqBF+TdGcuWmQzaGHygdVWmShIoS2JRN8Er3A4cBsI tzU5ccLSVOTO0QxzDphQ5L8qwCwjy8SJJ2gnwfPgXvmYMnZbB5docNgDsXMrLqGcFbx0 Y7X61F7/EzHQUOv/iNJQVytYt1jKcPvGFXK2LKiXrRSyEmweurceCpiwg54Q86T9pifb pfh/gDTQDL79h/82Mb1SWmbRRzVNlF9Gt+aHBpjD1FiwwEMi83l9HSEY9gyZJxt38C+n 9+1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779430258; x=1780035058; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ojcm6DVwDWABigVdQRXek9ypyb+6SWXapWuLW2WONAI=; b=D1RKQZQJK76SgouXX+UMaAy34zZJvi+Uk/Urg4ygqqdBIMG8cf3p1BJduPd10JV4lU WqH7fQK4EfXDyjNMAXaEjITzkXbuk9r9TcR4fyo/k2JRY/dMyRsNB7NE7kzVZS205X5N sxyqa8XnoM0Q1RaTdExP/uA5hVVqNDi8ckw26QglEHh2gQxkWGlxl/mXsx7xFdNj9rD1 oJzUVCk7bzgZLARytJ2yPSpNvzm2gZoT2/+Zs/gHKOltUHYgQ9TeKfXqmTptc14mveF0 zQSanVxguHBVfnbyfV8DBdbSNT87tOCmEQuWuDur/RbDWAH44eZ3+Zchd+e182xYuJPi OpAw== X-Forwarded-Encrypted: i=1; AFNElJ9n4LAuMvC0RM0cH0M1JIAksCrIXihk5hOho/iQWeEj8YhE7wTchWXLxLURhwC8HgPZYgsPcmB616CxQD67@postgresql.org X-Gm-Message-State: AOJu0Yy+4qL5rXs9xsuKyVztvG5AHZ1K6M3A51Xvfmx267qteBf3uVbD 0UcS7KOeEldzXphVsOapoQ6K1X9sm65Rw5wxYeyL4rXUXLY63SILt27xSIVYeYRmNwBLr2KMa1K poQhpE8D/MZz86rYuRT8VdeQtLbx3ECw= X-Gm-Gg: Acq92OHMZaUj2SMNautSvlf75xMsYFXMIPi7j9u2oWgXHFfHgrOxEHRXo8ICOcQM1G8 2YENQaftvsfcE/NmWzxCR4ysVSzP6GXqh+GToldVBih6djdznqYwNWaZblygZBwRXUIAElcLrGw 8MFfh1ChvYI1qmcXtrLQ3bk+YunPStRrciawgzGaghQpzgUbXN9K+AQiUd+mQbha+ZPbfVpLLNq 0gmikJUIq1dEPQ+vjzKNqwSc+ObJAUtwLbYX1nNlw6oxUClmu5ix5ZuSPN+NsFMFxTBOokfUdpB ioFqm2eAJpLq7TWBZw== X-Received: by 2002:a17:90b:5203:b0:35e:3e86:e2d1 with SMTP id 98e67ed59e1d1-36a67472320mr2236886a91.7.1779430257854; Thu, 21 May 2026 23:10:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Masahiko Sawada Date: Thu, 21 May 2026 23:10:20 -0700 X-Gm-Features: AVHnY4JX67SAWTRrtoQYaJ0JA-nY3SRnDMITIXfPv4dCObz7LGMX-RfpIu_o8PQ Message-ID: Subject: Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY) To: shveta malik Cc: Imran Zaheer , pgsql-hackers , shveta malik 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, May 21, 2026 at 9:19=E2=80=AFPM shveta malik wrote: > > On Thu, May 21, 2026 at 10:02=E2=80=AFPM Imran Zaheer wrote: > > > > Hi > > > > The recent support for dynamic toggling of logical decoding (67c2097) > > disables logical > > decoding if no logical slots are present. But the repack command doesn'= t seem to > > coordinate with this toggling. The effective_wal_level is not > > decreasing after using repack concurrently. > > > > postgres=3D# show effective_wal_level; > > effective_wal_level > > --------------------- > > replica > > (1 row) > > > > postgres=3D# create table foo(a int primary key); > > CREATE TABLE > > postgres=3D# REPACK (CONCURRENTLY) foo; > > 2026-05-21 20:46:25.423 PKT [1591896] LOG: logical decoding is > > enabled upon creating a new logical replication slot > > 2026-05-21 20:46:25.634 PKT [1591896] LOG: logical decoding found > > consistent point at 0/018F36D0 > > 2026-05-21 20:46:25.634 PKT [1591896] DETAIL: There are no running > > transactions. > > REPACK > > postgres=3D# select slot_name from pg_replication_slots; > > slot_name > > ----------- > > (0 rows) > > > > postgres=3D# show effective_wal_level; > > effective_wal_level > > --------------------- > > logical > > (1 row) > > > > > > The server has to be restarted in order to decrease the > > effective_wal_level. REPACK CONCURRENTLY uses a temporary slot that is > > dropped at the time of cleanup, but logical decoding is not disabled. > > > > This may be related to both commits, 28d534e and 67c2097 > > > > The attached patch adds the `RequestDisableLogicalDecoding` call to > > `repack_cleanup_logical_decoding` after the replication slot is > > dropped so the checkpointer will take care of it.. > > Good catch! > > Thanks for reporting the issue. I agree with both the problem > statement and the proposed fix. > > The fix LGTM. The only point I=E2=80=99d like to discuss is whether it wo= uld > make more sense for RequestDisableLogicalDecoding() to be called > directly from ReplicationSlotDropAcquired(). > > Currently, ReplicationSlotRelease(), ReplicationSlotDrop(), and now > repack_cleanup_logical_decoding() all invoke > RequestDisableLogicalDecoding() immediately after > ReplicationSlotDropAcquired(). Given this pattern, it may be cleaner > and less error-prone to make RequestDisableLogicalDecoding() part of > ReplicationSlotDropAcquired() itself, which could also help avoid > similar bugs in the future. > > That said, one concern is that ReplicationSlotsDropDBSlots() could end > up issuing too many disable requests if there are many logical slots > in the target database, so I=E2=80=99m not entirely sure whether this is = the > right direction. Thoughts? Good point. I think we can have ReplicationSlotDropAcquired() have a flag to skip sending a deactivation request. That way, ReplicationSlotsDropDBSlots() can check the logical slot presence after processing all slots and other callers can request the deactivation after dropping the slot. It would help simplify the code somewhat. It's conventional that when dropping a slot we acquire the slot first and call RepicationSlotDropAcquired() to reliably drop a slot (ReplicationSlotCleanup() is an exception). Therefore, I think that having a flag to ReplicationSlotDropAcquired() could help future developers to make sure to disable logical decoding at the slot drop. Regards, --=20 Masahiko Sawada Amazon Web Services: https://aws.amazon.com