| From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
|---|---|
| To: | Sami Imseih <samimseih(dot)pg(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-10-28 21:48:45 |
| Message-ID: | CAD21AoDmeKt1UvDkr_eqHTMUquWaQTm27_tDXStts-U3+kqmTQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 24, 2026 at 10:42 AM Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> wrote:
>
> > Thank you for updating the patch! I've pushed the 0001 patch as it
> > looks good to me.
> >
> > I'll review 0002 patch and send review comments.
>
> Thanks!
I've reviewed the patch and it mostly looks good to me. I have one
minor comment:
/* Find our decoding starting point. */
+ set_repack_worker_setup_phase(shared,
+ PROGRESS_REPACK_PHASE_INIT_LOGICAL_DECODING);
DecodingContextFindStartpoint(ctx);
While it's true that DecodingContextFindStartpoint() is the call that
can take a long time in this phase, I'd recommend setting the
INIT_LOGICAL_DECODING phase just before calling
CreateInitDecodingContext(). Otherwise, if CreateInitDecodingContext()
takes time for some reason, it would be reported as "enabling logical
decoding", which the documentation describes as having nothing to do
when effective_wal_level is already logical.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2026-10-28 22:12:58 | Re: Add REPACK progress phases for logical decoding setup |
| Previous Message | surya poondla | 2026-10-28 21:33:33 | Re: Be strict when request to flush past end of WAL in WaitXLogInsertionsToFinish |