Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix 051_effective_wal_level.pl on builds without injection points.

  2. Disable logical decoding after REPACK (CONCURRENTLY)

  1. effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

    Imran Zaheer <imran.zhir@gmail.com> — 2026-05-21T16:32:36Z

    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=# show effective_wal_level;
 effective_wal_level
---------------------
 replica
(1 row)

postgres=# create table foo(a int primary key);
CREATE TABLE
postgres=# 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=# select slot_name from pg_replication_slots;
 slot_name
-----------
(0 rows)

postgres=# 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..


Thanks
Imran Zaheer

  2. Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

    shveta malik <shveta.malik@gmail.com> — 2026-05-22T04:18:54Z

    On Thu, May 21, 2026 at 10:02 PM Imran Zaheer <imran.zhir@gmail.com> 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=# show effective_wal_level;
>  effective_wal_level
> ---------------------
>  replica
> (1 row)
>
> postgres=# create table foo(a int primary key);
> CREATE TABLE
> postgres=# 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=# select slot_name from pg_replication_slots;
>  slot_name
> -----------
> (0 rows)
>
> postgres=# 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..
>

Thanks for reporting the issue. I agree with both the problem
statement and the proposed fix.

The fix LGTM. The only point I’d like to discuss is whether it would
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’m not entirely sure whether this is the
right direction. Thoughts?

Copying Sawada-san (author of the original patch) too, to share his
thoughts on this.

thanks
Shveta

  3. Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

    Masahiko Sawada <sawada.mshk@gmail.com> — 2026-05-22T06:10:20Z

    On Thu, May 21, 2026 at 9:19 PM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Thu, May 21, 2026 at 10:02 PM Imran Zaheer <imran.zhir@gmail.com> 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=# show effective_wal_level;
> >  effective_wal_level
> > ---------------------
> >  replica
> > (1 row)
> >
> > postgres=# create table foo(a int primary key);
> > CREATE TABLE
> > postgres=# 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=# select slot_name from pg_replication_slots;
> >  slot_name
> > -----------
> > (0 rows)
> >
> > postgres=# 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’d like to discuss is whether it would
> 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’m 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,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

  4. Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

    shveta malik <shveta.malik@gmail.com> — 2026-05-22T08:57:37Z

    On Fri, May 22, 2026 at 11:40 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Thu, May 21, 2026 at 9:19 PM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Thu, May 21, 2026 at 10:02 PM Imran Zaheer <imran.zhir@gmail.com> 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=# show effective_wal_level;
> > >  effective_wal_level
> > > ---------------------
> > >  replica
> > > (1 row)
> > >
> > > postgres=# create table foo(a int primary key);
> > > CREATE TABLE
> > > postgres=# 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=# select slot_name from pg_replication_slots;
> > >  slot_name
> > > -----------
> > > (0 rows)
> > >
> > > postgres=# 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’d like to discuss is whether it would
> > 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’m 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.
>

Yes, that seems like a good proposal. Having an explicit argument
would require authors to consciously review and decide whether logical
decoding should be disabled based on their specific use case. That
would help prevent such bugs from being introduced unintentionally.

thanks
Shveta

  5. Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

    Imran Zaheer <imran.zhir@gmail.com> — 2026-05-23T09:19:30Z

    Hi

Thanks for the review. In the attached patch, I added an argument that
will help explicitly control whether to stop logical decoding or not.

-ReplicationSlotDropAcquired(void)
+ReplicationSlotDropAcquired(bool disable_logical_decoding)

I hope this will be enough to make the caller intent more explicit and
will prevent future omissions like this.

Thanks
Imran Zaheer

On Fri, May 22, 2026 at 1:57 PM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Fri, May 22, 2026 at 11:40 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Thu, May 21, 2026 at 9:19 PM shveta malik <shveta.malik@gmail.com> wrote:
> > >
> > > On Thu, May 21, 2026 at 10:02 PM Imran Zaheer <imran.zhir@gmail.com> 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=# show effective_wal_level;
> > > >  effective_wal_level
> > > > ---------------------
> > > >  replica
> > > > (1 row)
> > > >
> > > > postgres=# create table foo(a int primary key);
> > > > CREATE TABLE
> > > > postgres=# 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=# select slot_name from pg_replication_slots;
> > > >  slot_name
> > > > -----------
> > > > (0 rows)
> > > >
> > > > postgres=# 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’d like to discuss is whether it would
> > > 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’m 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.
> >
>
> Yes, that seems like a good proposal. Having an explicit argument
> would require authors to consciously review and decide whether logical
> decoding should be disabled based on their specific use case. That
> would help prevent such bugs from being introduced unintentionally.
>
> thanks
> Shveta

  6. Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

    shveta malik <shveta.malik@gmail.com> — 2026-05-25T04:11:38Z

    On Sat, May 23, 2026 at 2:49 PM Imran Zaheer <imran.zhir@gmail.com> wrote:
>
> Hi
>
> Thanks for the review. In the attached patch, I added an argument that
> will help explicitly control whether to stop logical decoding or not.
>
> -ReplicationSlotDropAcquired(void)
> +ReplicationSlotDropAcquired(bool disable_logical_decoding)
>
> I hope this will be enough to make the caller intent more explicit and
> will prevent future omissions like this.
>

Overall it looks good. I have a few trivial comments; please
incorporate them if you agree.

1)
+ReplicationSlotDropAcquired(bool disable_logical_decoding)

We can change comments atop this function. Suggestion :

/*
 * Permanently drop the currently acquired replication slot and
 * request the checkpointer to disable logical decoding if requested
 * by the caller.
 */


2)
Additionally I think it will be good to have below sanity check in
ReplicationSlotDropAcquired(). Thoughts?

/* Ensure that slot is logical if caller has requested to disable
logical decoding */
Assert(!disable_logical_decoding || SlotIsLogical(MyReplicationSlot));

3)
@@ -567,7 +567,7 @@ drop_local_obsolete_slots(List *remote_slot_list)
  if (synced_slot)
  {
  ReplicationSlotAcquire(NameStr(local_slot->data.name), true, false);
- ReplicationSlotDropAcquired();
+ ReplicationSlotDropAcquired(false);
  }

Since it is a logical slot and we are still passing false, we may add
a comment. Suggestion:

/*
 * We don't want to disable logical decoding during slot drop on the
 * physical standby, since the standby derives the logical decoding
 * state from the upstream server in the replication chain.
 */

thanks
Shveta

  7. Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

    Imran Zaheer <imran.zhir@gmail.com> — 2026-05-26T09:39:29Z

    Hi,

Thanks Shveta,  I agree with the additional sanity checks and comments.

Here is the updated patch.


Thanks
Imran Zaheer

On Mon, May 25, 2026 at 9:11 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Sat, May 23, 2026 at 2:49 PM Imran Zaheer <imran.zhir@gmail.com> wrote:
> >
> > Hi
> >
> > Thanks for the review. In the attached patch, I added an argument that
> > will help explicitly control whether to stop logical decoding or not.
> >
> > -ReplicationSlotDropAcquired(void)
> > +ReplicationSlotDropAcquired(bool disable_logical_decoding)
> >
> > I hope this will be enough to make the caller intent more explicit and
> > will prevent future omissions like this.
> >
>
> Overall it looks good. I have a few trivial comments; please
> incorporate them if you agree.
>
> 1)
> +ReplicationSlotDropAcquired(bool disable_logical_decoding)
>
> We can change comments atop this function. Suggestion :
>
> /*
>  * Permanently drop the currently acquired replication slot and
>  * request the checkpointer to disable logical decoding if requested
>  * by the caller.
>  */
>
>
> 2)
> Additionally I think it will be good to have below sanity check in
> ReplicationSlotDropAcquired(). Thoughts?
>
> /* Ensure that slot is logical if caller has requested to disable
> logical decoding */
> Assert(!disable_logical_decoding || SlotIsLogical(MyReplicationSlot));
>
> 3)
> @@ -567,7 +567,7 @@ drop_local_obsolete_slots(List *remote_slot_list)
>   if (synced_slot)
>   {
>   ReplicationSlotAcquire(NameStr(local_slot->data.name), true, false);
> - ReplicationSlotDropAcquired();
> + ReplicationSlotDropAcquired(false);
>   }
>
> Since it is a logical slot and we are still passing false, we may add
> a comment. Suggestion:
>
> /*
>  * We don't want to disable logical decoding during slot drop on the
>  * physical standby, since the standby derives the logical decoding
>  * state from the upstream server in the replication chain.
>  */
>
> thanks
> Shveta

  8. Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

    shveta malik <shveta.malik@gmail.com> — 2026-05-26T12:32:09Z

    On Tue, May 26, 2026 at 3:09 PM Imran Zaheer <imran.zhir@gmail.com> wrote:
>
> Hi,
>
> Thanks Shveta,  I agree with the additional sanity checks and comments.
>
> Here is the updated patch.
>
>

Thanks, v3 LGTM.

thanks
Shveta

  9. Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-05-27T18:20:48Z

    On 2026-May-26, shveta malik wrote:

> On Tue, May 26, 2026 at 3:09 PM Imran Zaheer <imran.zhir@gmail.com> wrote:
> >
> > Hi,
> >
> > Thanks Shveta,  I agree with the additional sanity checks and comments.
> 
> Thanks, v3 LGTM.

Thanks!  Pushed with some cosmetic changes.

One of them was that I wasn't sure of the reason why ApplyLauncherMain()
isn't requesting logical decoding disable upon dropping the slot, so
there's now an XXX comment there.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Java is clearly an example of money oriented programming"  (A. Stepanov)

  10. Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

    Masahiko Sawada <sawada.mshk@gmail.com> — 2026-05-27T18:25:19Z

    On Wed, May 27, 2026 at 11:20 AM Álvaro Herrera <alvherre@kurilemu.de> wrote:
>
> On 2026-May-26, shveta malik wrote:
>
> > On Tue, May 26, 2026 at 3:09 PM Imran Zaheer <imran.zhir@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > Thanks Shveta,  I agree with the additional sanity checks and comments.
> >
> > Thanks, v3 LGTM.
>
> Thanks!  Pushed with some cosmetic changes.

Thank you for pushing the patch!

>
> One of them was that I wasn't sure of the reason why ApplyLauncherMain()
> isn't requesting logical decoding disable upon dropping the slot, so
> there's now an XXX comment there.

This is because the launcher can acquire only CONFLICT_DETECTION_SLOT
slot and it is a physical slot.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

  11. Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

    Masahiko Sawada <sawada.mshk@gmail.com> — 2026-05-27T18:56:07Z

    On Wed, May 27, 2026 at 11:25 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, May 27, 2026 at 11:20 AM Álvaro Herrera <alvherre@kurilemu.de> wrote:
> >
> > On 2026-May-26, shveta malik wrote:
> >
> > > On Tue, May 26, 2026 at 3:09 PM Imran Zaheer <imran.zhir@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Thanks Shveta,  I agree with the additional sanity checks and comments.
> > >
> > > Thanks, v3 LGTM.
> >
> > Thanks!  Pushed with some cosmetic changes.
>
> Thank you for pushing the patch!

Some buildfarm members reported failures[1][2]. The newly added test
works only on builds without injection points because the logical slot
"test_slot" is removed during tests using injection points, otherwise
it still exists on the primary server at the end of
051_effective_wal_level.pl.

Regards,

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=loach&dt=2026-05-27%2018%3A25%3A00
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=goldfish&dt=2026-05-27%2018%3A15%3A02

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

  12. Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

    Masahiko Sawada <sawada.mshk@gmail.com> — 2026-05-27T19:21:18Z

    On Wed, May 27, 2026 at 11:56 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, May 27, 2026 at 11:25 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Wed, May 27, 2026 at 11:20 AM Álvaro Herrera <alvherre@kurilemu.de> wrote:
> > >
> > > On 2026-May-26, shveta malik wrote:
> > >
> > > > On Tue, May 26, 2026 at 3:09 PM Imran Zaheer <imran.zhir@gmail.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Thanks Shveta,  I agree with the additional sanity checks and comments.
> > > >
> > > > Thanks, v3 LGTM.
> > >
> > > Thanks!  Pushed with some cosmetic changes.
> >
> > Thank you for pushing the patch!
>
> Some buildfarm members reported failures[1][2]. The newly added test
> works only on builds without injection points because the logical slot
> "test_slot" is removed during tests using injection points, otherwise
> it still exists on the primary server at the end of
> 051_effective_wal_level.pl.
>

I've attached the patch to fix the issue by moving the new test
earlier in the test script, so it no longer depends on slot state.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

  13. Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-05-27T21:20:43Z

    On 2026-May-27, Masahiko Sawada wrote:

> > Some buildfarm members reported failures[1][2]. The newly added test
> > works only on builds without injection points because the logical slot
> > "test_slot" is removed during tests using injection points, otherwise
> > it still exists on the primary server at the end of
> > 051_effective_wal_level.pl.
> >
> 
> I've attached the patch to fix the issue by moving the new test
> earlier in the test script, so it no longer depends on slot state.

Ah, so that's why the submitted patch had the test placed at an awkward
place in the file!  I moved it to the end because I failed to realize
this problem.  I didn't see this failure locally, and CI didn't see it
either.  I wonder if we're lacking coverage of the no-injection-points
case in CI.

Thanks for the patch, please feel free to push it.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"People get annoyed when you try to debug them."  (Larry Wall)

  14. Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)

    Masahiko Sawada <sawada.mshk@gmail.com> — 2026-05-27T22:56:48Z

    On Wed, May 27, 2026 at 2:20 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
>
> On 2026-May-27, Masahiko Sawada wrote:
>
> > > Some buildfarm members reported failures[1][2]. The newly added test
> > > works only on builds without injection points because the logical slot
> > > "test_slot" is removed during tests using injection points, otherwise
> > > it still exists on the primary server at the end of
> > > 051_effective_wal_level.pl.
> > >
> >
> > I've attached the patch to fix the issue by moving the new test
> > earlier in the test script, so it no longer depends on slot state.
>
> Ah, so that's why the submitted patch had the test placed at an awkward
> place in the file!  I moved it to the end because I failed to realize
> this problem.  I didn't see this failure locally, and CI didn't see it
> either.  I wonder if we're lacking coverage of the no-injection-points
> case in CI.

I happened to notice the failure when testing other codes locally. It
would be good to have no-injection-points cases in CI.

> Thanks for the patch, please feel free to push it.

Pushed. Thank you for reviewing the patch!

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com