Hi,
On Tue, Apr 1, 2025 at 10:31 AM Antonin Houska <ah@cybertec.at> wrote:
> One more version, hopefully to make cfbot happy (I missed the bug because I
> did not set the RELCACHE_FORCE_RELEASE macro in my environment.)
Thanks for the new version! I'm starting to study this patch series and
I just want to share some points about the documentation on v12-0004:
+ Thus the tuples inserted into the old file during the copying are
+ also stored in separately in a temporary file, so they can eventually
Maybe "stored separately in a temporary file"?
+ <row>
+ <entry><literal>catch-up</literal></entry>
+ <entry>
+ <command>REPACK</command> is currently processing the DML commands that
+ other transactions executed during any of the preceding phase.
+ </entry>
+ </row>
This catch-up phase only happens when CONCURRENTLY is used right? Maybe
it would be good to mention this?
The commit message say:
"Of course, more data changes can take place while we are waiting for
the lock - these will be applied to the new file after we have acquired
the lock, before we swap the files."
But the documentation say:
+ <para>
+ With the <literal>CONCURRENTLY</literal> option, the <literal>ACCESS
+ EXCLUSIVE</literal> lock is only acquired to swap the table and index
+ files. The data changes that took place during the creation of the new
+ table and index files are captured using logical decoding
+ (<xref linkend="logicaldecoding"/>) and applied before
+ the <literal>ACCESS EXCLUSIVE</literal> lock is requested. Thus the lock
+ is typically held only for the time needed to swap the files, which
+ should be pretty short.
+ </para>
I've noticed that you've included on 0007 that the ACCESS EXCLUSIVE may
be used to apply changes that occurred while waiting for the lock, but
IIUC this behaviour is implemented on 0004 right? If that's the case I
think that it would be good to move this part of the documentation to
0004 instead of 0007, what do you think?
--
Matheus Alcantara
