Re: Initial COPY of Logical Replication is too slow - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Initial COPY of Logical Replication is too slow
Date
Msg-id CAD21AoAfXAUhLzo4tHM9ssA4SGGSZoZPwrxf5mcp9k8zJ8zr5g@mail.gmail.com
Whole thread
In response to RE: Initial COPY of Logical Replication is too slow  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Responses Re:Re: Initial COPY of Logical Replication is too slow
RE: Initial COPY of Logical Replication is too slow
List pgsql-hackers
On Mon, Mar 30, 2026 at 12:16 AM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Friday, March 27, 2026 2:20 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > I've attached the updated patch. I believe I've addressed all comments I got
> > so far. In addition to that, I've refactored
> > is_table_publishable_in_publication() and added more regression tests.
>
> Thanks for updating the patch.
>
> The latest patch looks mostly good to me. However, I noticed one issue: the
> function returns table information even for unlogged or temporary tables. I
> think we should return NULL for those cases instead.

Indeed. Good catch!

>
> BTW, I think we could use is_publishable_class() as a reference to check once
> whether all unpublishable table types are properly ignored in this function.
>

+1. I've added is_publishable_class() check.

I've attached the updated patch.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Skipping schema changes in publication
Next
From: John Naylor
Date:
Subject: Re: Proposal for enabling auto-vectorization for checksum calculations