Thread

1. repack: clarify final phase of concurrent mode in file header comment

   Chao Li <li.evan.chao@gmail.com> — 2026-04-16T03:32:40Z

   Hi,
   
   The file header comment in repack.c briefly explains the workflow of concurrent mode as:
   
   1. Lock the table with ShareUpdateExclusiveLock
   2. Do an initial copy as non-concurrent mode
   3. While the initial copy is going on, accumulates concurrent changes to a file
   4. After the initial copy, read the file and re-apply the changes
   5. Upgrade to AccessExclusiveLock and swap the relfilenodes
   
   When I read the comment, I got confused at step 4. While that re-apply pass is running, concurrent changes can still occur, so what happens to those changes?
   
   After reading the code, I see that there is actually an extra step after upgrading to AccessExclusiveLock to process the remaining changes.
   
   I am afraid other readers may have the same confusion, so I am proposing this small patch to make the file header comment a bit clearer.
   
   Best regards,
   --
   Chao Li (Evan)
   HighGo Software Co., Ltd.
   https://www.highgo.com/
   
   

2. Re: repack: clarify final phase of concurrent mode in file header comment

   Jakub Wartak <jakub.wartak@enterprisedb.com> — 2026-06-10T08:33:36Z

   On Thu, Apr 16, 2026 at 5:33 AM Chao Li <li.evan.chao@gmail.com> wrote:
   >
   > Hi,
   >
   > The file header comment in repack.c briefly explains the workflow of concurrent mode as:
   >
   > 1. Lock the table with ShareUpdateExclusiveLock
   > 2. Do an initial copy as non-concurrent mode
   > 3. While the initial copy is going on, accumulates concurrent changes to a file
   > 4. After the initial copy, read the file and re-apply the changes
   > 5. Upgrade to AccessExclusiveLock and swap the relfilenodes
   >
   > When I read the comment, I got confused at step 4. While that re-apply pass is running, concurrent changes can still occur, so what happens to those changes?
   >
   > After reading the code, I see that there is actually an extra step after upgrading to AccessExclusiveLock to process the remaining changes.
   >
   > I am afraid other readers may have the same confusion, so I am proposing this small patch to make the file header comment a bit clearer.
   
   LGTM, so +1
   
   -J.
   
   
   
   

3. Re: repack: clarify final phase of concurrent mode in file header comment

   Chao Li <li.evan.chao@gmail.com> — 2026-06-10T09:21:40Z

   
   > On Jun 10, 2026, at 16:33, Jakub Wartak <jakub.wartak@enterprisedb.com> wrote:
   > 
   > On Thu, Apr 16, 2026 at 5:33 AM Chao Li <li.evan.chao@gmail.com> wrote:
   >> 
   >> Hi,
   >> 
   >> The file header comment in repack.c briefly explains the workflow of concurrent mode as:
   >> 
   >> 1. Lock the table with ShareUpdateExclusiveLock
   >> 2. Do an initial copy as non-concurrent mode
   >> 3. While the initial copy is going on, accumulates concurrent changes to a file
   >> 4. After the initial copy, read the file and re-apply the changes
   >> 5. Upgrade to AccessExclusiveLock and swap the relfilenodes
   >> 
   >> When I read the comment, I got confused at step 4. While that re-apply pass is running, concurrent changes can still occur, so what happens to those changes?
   >> 
   >> After reading the code, I see that there is actually an extra step after upgrading to AccessExclusiveLock to process the remaining changes.
   >> 
   >> I am afraid other readers may have the same confusion, so I am proposing this small patch to make the file header comment a bit clearer.
   > 
   > LGTM, so +1
   > 
   > -J.
   
   Thanks for the review.
   
   Rebased to v2.
   
   Best regards,
   --
   Chao Li (Evan)
   HighGo Software Co., Ltd.
   https://www.highgo.com/