| From: | Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add REPACK progress phases for logical decoding setup |
| Date: | 2026-09-23 20:25:42 |
| Message-ID: | CAN12+YKHgQspCLSNFkMAhWjsiBcyGWBY1kKCMO=PCjDFE2jsyg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I've reviewed the 0001 patch first as it's an open item. There are
> some minor comments:
Thanks!
> - expected to be very brief.
> + expected to be very brief, except for
> + <command>REPACK (CONCURRENTLY)</command>, where it also covers enabling
> + logical decoding and then initializing it. Enabling has nothing to do
> + if <xref linkend="guc-effective-wal-level"/> is already
> + <literal>logical</literal>; otherwise it waits for all backends to
> + acknowledge that they started writing the additional WAL information
> + that logical decoding requires. Initializing then waits for the
>
> The logical decoding activation waits for all processes to acknowledge
> it, not only backends.
Fair. I updated it.
> + transactions that had already been assigned a transaction ID to end, so
> + this phase can last as long as the longest of those transactions.
>
> During the logical decoding initialization, the snapshot builder also
> has to wait for transactions that started after the initialization
> began (i.e., those that started while it was in the BUILDING_SNAPSHOT
> state). So this phase can last longer than the longest of the
> transactions that
> were running when it started. How about rephrasing it as follows?
>
> expected to be very brief, except for
> <command>REPACK (CONCURRENTLY)</command>, where it also covers enabling
> logical decoding and then initializing it. Enabling has nothing to do
> if <xref linkend="guc-effective-wal-level"/> is already
> <literal>logical</literal>; otherwise it waits for all processes to
> acknowledge that they started writing the additional WAL information
> that logical decoding requires. Initializing then waits for the
> transactions that have been assigned a transaction ID to end,
> including ones that started while this wait was in progress, so this
> phase can last longer than the longest transaction running when the
> command started.
Good point. I used what you provided and I realized that in my v1 I was also
specifically calling out that "waits for the transactions that have
been assigned a transaction ID to end"
also includes other REPACK CONCURRENTLY operations. This may not be obvious,
so it's worth a callout.
--
Sami Imseih
Amazon Web Services (AWS)
| Attachment | Content-Type | Size |
|---|---|---|
| v4-0002-Add-REPACK-progress-phases-for-logical-decoding-s.patch | application/octet-stream | 11.6 KB |
| v4-0001-doc-Improve-REPACK-phase-documentation-for-long-o.patch | application/octet-stream | 3.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lukas Fittl | 2026-09-23 20:26:41 | Re: PostgreSQL 19 Beta 4 release announcement draft |
| Previous Message | Andrew Dunstan | 2026-09-23 20:12:40 | Re: 64-bit MultiXactOffset vs. 9.3->9.4 upgrade, pg_resetwal, "wraparound" msg |