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 a race condition in updating procArray->replication_slot_xmin.

  1. [PATCH] Fix TOCTOU race in ReplicationSlotsComputeRequiredLSN()

    JoongHyuk Shin <sjh910805@gmail.com> — 2026-04-17T06:50:01Z

    Hi,
    
    Commit 2a5225b99d7 fixed a race in ReplicationSlotsComputeRequiredXmin()
    where ReplicationSlotControlLock was released before the global xmin
    update, allowing a concurrent backend to overwrite a correct value with
    a stale one.
    
    ReplicationSlotsComputeRequiredLSN() has the same problem, it releases the
    lock before calling XLogSetReplicationSlotMinimumLSN(), so a stale minimum
    LSN can overwrite a correct (lower) one, potentially leading to premature
    WAL removal.
    
    The attached patch moves LWLockRelease() to after the LSN update,
    matching the xmin fix. Since 2a5225b99d7 was backpatched to all supported
    versions, I believe this should be as well.
    
  2. RE: [PATCH] Fix TOCTOU race in ReplicationSlotsComputeRequiredLSN()

    Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> — 2026-04-17T06:59:14Z

    On Friday, April 17, 2026 2:50 PM JoongHyuk Shin <sjh910805@gmail.com>  wrote:
    > Commit 2a5225b99d7 fixed a race in ReplicationSlotsComputeRequiredXmin()
    > where ReplicationSlotControlLock was released before the global xmin
    > update, allowing a concurrent backend to overwrite a correct value with
    > a stale one.
    > 
    > ReplicationSlotsComputeRequiredLSN() has the same problem, 
    > it releases the lock before calling XLogSetReplicationSlotMinimumLSN(), 
    > so a stale minimum LSN can overwrite a correct (lower) one, 
    > potentially leading to premature WAL removal.
    > 
    > The attached patch moves LWLockRelease() to after the LSN update,
    > matching the xmin fix.
    > Since 2a5225b99d7 was backpatched to all supported versions, 
    > I believe this should be as well.
    
    Thanks for noticing this. There is an existing thread [1] that I started
    following 2a5225b99d7 to address the same issue. The patch you posted
    only increases the lock scope in ReplicationSlotsComputeRequiredLSN() but does
    not increase the lock level when reserving WALs, so I think it would not
    fix the issue.
    
    Please feel free to review the patch in that thread if you find it helpful.
    
    [1] https://commitfest.postgresql.org/patch/6451/
    
    Best Regards,
    Hou zj
    
  3. Re: [PATCH] Fix TOCTOU race in ReplicationSlotsComputeRequiredLSN()

    JoongHyuk Shin <sjh910805@gmail.com> — 2026-04-17T07:46:31Z

    Hi Zhijie,
    
    Thanks for pointing this out.
    You're right that my patch only covers the read side
    and misses the write side in ReplicationSlotReserveWal().
    I should have checked for existing work before submitting.
    
    I'll withdraw this patch.
    
    Best Regards,
    JoongHyuk Shin
    
    On Fri, Apr 17, 2026 at 3:59 PM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
    wrote:
    
    > On Friday, April 17, 2026 2:50 PM JoongHyuk Shin <sjh910805@gmail.com>
    > wrote:
    > > Commit 2a5225b99d7 fixed a race in ReplicationSlotsComputeRequiredXmin()
    > > where ReplicationSlotControlLock was released before the global xmin
    > > update, allowing a concurrent backend to overwrite a correct value with
    > > a stale one.
    > >
    > > ReplicationSlotsComputeRequiredLSN() has the same problem,
    > > it releases the lock before calling XLogSetReplicationSlotMinimumLSN(),
    > > so a stale minimum LSN can overwrite a correct (lower) one,
    > > potentially leading to premature WAL removal.
    > >
    > > The attached patch moves LWLockRelease() to after the LSN update,
    > > matching the xmin fix.
    > > Since 2a5225b99d7 was backpatched to all supported versions,
    > > I believe this should be as well.
    >
    > Thanks for noticing this. There is an existing thread [1] that I started
    > following 2a5225b99d7 to address the same issue. The patch you posted
    > only increases the lock scope in ReplicationSlotsComputeRequiredLSN() but
    > does
    > not increase the lock level when reserving WALs, so I think it would not
    > fix the issue.
    >
    > Please feel free to review the patch in that thread if you find it helpful.
    >
    > [1] https://commitfest.postgresql.org/patch/6451/
    >
    > Best Regards,
    > Hou zj
    >