On Fri, Mar 28, 2025 at 10:46 AM Hayato Kuroda (Fujitsu)
wrote:
>
> > The problem here is that after ALTER SUBSCRIPTION tap_sub SET
> > PUBLICATION ..., we didn't wait for the new walsender on publisher to
> > start. We must use wait_for_subscription_sync both after the "CREATE
> > SUBSCRIPTION ..
Dear Amit,
> The problem here is that after ALTER SUBSCRIPTION tap_sub SET
> PUBLICATION ..., we didn't wait for the new walsender on publisher to
> start. We must use wait_for_subscription_sync both after the "CREATE
> SUBSCRIPTION ..." and the "ALTER SUBSCRIPTION ..." commands and keep
> copy_da
On Fri, Mar 28, 2025 at 6:03 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Andres,
>
> > I think the new tests just failed in CI:
> > https://cirrus-ci.com/task/5602950271205376?logs=test_world#L268
>
> Thanks for reporting, I'll look into it.
>
The problem here is that after ALTER SUBSCRIPTION tap_
Dear Andres,
> I think the new tests just failed in CI:
> https://cirrus-ci.com/task/5602950271205376?logs=test_world#L268
Thanks for reporting, I'll look into it.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
Hi,
On 2025-03-13 14:13:39 +0530, Amit Kapila wrote:
> On Wed, Mar 12, 2025 at 5:46 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > > Thanks, the patch looks mostly good to me. I have made few cosmetic
> > > changes in the attached and combined both the patches.
> >
> > Thanks, it looks good to me.
>
On Wed, Mar 12, 2025 at 5:46 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > Thanks, the patch looks mostly good to me. I have made few cosmetic
> > changes in the attached and combined both the patches.
>
> Thanks, it looks good to me.
>
> > The existing
> > Alter Publication ... Rename tests don't test
Dear Amit,
> Thanks, the patch looks mostly good to me. I have made few cosmetic
> changes in the attached and combined both the patches.
Thanks, it looks good to me.
> The existing
> Alter Publication ... Rename tests don't test invalidations arising
> from that command. As this patch changes t
On Tue, Mar 11, 2025 at 5:47 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Attached patch address comments by you and Amit [1]. What's new;
>
Thanks, the patch looks mostly good to me. I have made few cosmetic
changes in the attached and combined both the patches. The existing
Alter Publication ... Renam
Dear Amit, Hou,
Thanks for giving comments!
> For patch 0002, I think the implementation could be improved. The
> current patch introduces a new function, RenamePublication, to replace the
> existing generic approach in ExecRenameStmt->AlterObjectRename_internal.
> However, this creates inconsist
On Monday, March 10, 2025 9:12 PM Kuroda, Hayato
wrote:
>
> > Currently, only the leaf partition is invalidated when the published
> > table is partitioned. However, I think pgoutput could cache both the
> > partitioned table and the leaf partition table as relsync entries.
> >
> > For INSERT/UP
On Mon, Mar 10, 2025 at 6:42 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > Currently, only the leaf partition is invalidated when the published table
> > is
> > partitioned. However, I think pgoutput could cache both the partitioned
> > table
> > and the leaf partition table as relsync entries.
> >
>
Dear Hou,
> Currently, only the leaf partition is invalidated when the published table is
> partitioned. However, I think pgoutput could cache both the partitioned table
> and the leaf partition table as relsync entries.
>
> For INSERT/UPDATE/DELETE on a partitioned table, only the leaf partition
On Monday, March 10, 2025 7:00 PM Kuroda, Hayato
wrote:
>
> I did a self-reviewing and updated a patch. PSA new version. What's new:
Thanks for updating the patch.
I tested the behavior for partitioned table and have a comment on this.
> + relids = GetPublicationRelations(pubform-
Dear hackers,
I did a self-reviewing and updated a patch. PSA new version. What's new:
1. Fixed a bug which existing name can be specified by ALTER PUBLICATION RENAME.
A validation is added in RenamePublication().
Just in case, we want to discuss the case that the renaming publication has
th
I found cfbot got angry due to a variable-shadowing. PSA fixed version.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
v7-0001-Introduce-a-new-invalidation-message-to-invalidat.patch
Description: v7-0001-Introduce-a-new-invalidation-message-to-invalidat.patch
v7-0002-Invalidate-Relcaches-while-
Dear Amit,
> Don't we need to call this invalidation function from
> InvalidateSystemCachesExtended()?
Hmm. I did not call relsync callback functions in
InvalidateSystemCachesExtended()
intentionally, but added now. Please see my analysis below and let me know how
you think.
In the first place,
Dear Amit, hackers,
> Yeah, this is a good improvement and the patch looks safe to me, so I
> pushed with minor changes in the comments.
Thanks! PSA rebased patch. While considering more about 0002, I found a
conceptual bug - when relsync cache could not be re-built when SQL interfaces
are
used.
On Fri, Mar 7, 2025 at 4:28 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Amit,
>
> Thanks for the comment! PSA new version.
>
Don't we need to call this invalidation function from
InvalidateSystemCachesExtended()?
--
With Regards,
Amit Kapila.
Dear Amit,
Thanks for the comment! PSA new version.
>
> Few comments:
> 1. Why do we need to invalidate relsync entries when owner of its
> publication changes?
>
> I think the owner change will impact the future Alter Publication ...
> Add/Drop/Set/Rename operations as that will be allowed onl
Dear hackers,
> Hmm. It requires additional debug messages. Let me consider.
I did further performance testing to see the re-building time, and confirmed
that
the decoding time of second INSERT part became around 1/10. In this test number
of partitions was also varied. Each cell is a median of 5
On Thu, Mar 6, 2025 at 5:16 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Amit, hackers,
>
> > Yeah, this is a good improvement and the patch looks safe to me, so I
> > pushed with minor changes in the comments.
>
> Thanks! PSA rebased patch.
>
Few comments:
1. Why do we need to invalidate relsync e
On Wed, Mar 5, 2025 at 2:35 PM Hayato Kuroda (Fujitsu)
wrote:
>
> I did a performance testing with HEAD and v2-0001, and confirmed that it could
> improve performance around 20% in the typical case.
>
> Workload
> ==
> I emulated a scenario that there are many tables to be published and only o
Dear hackers,
I did a performance testing with HEAD and v2-0001, and confirmed that it could
improve performance around 20% in the typical case.
Workload
==
I emulated a scenario that there are many tables to be published and only one
table is stop and resume publishing. In HEAD, ALTER PUBLIC
Dear Hou,
Thanks for reading the thread!
> > Attached patchset implemented with the approach.
> > 0001 contains only part to avoid whole cache invalidation, for ADD/SET/DROP
> > command.
>
> I think the changes proposed in 0001 are reasonable. Basically, any
> modifications to pg_publication_rel
On Tuesday, March 4, 2025 7:44 PM Kuroda, Hayato/黒田 隼人
wrote:
Hi,
>
> > > When the ALTER PUBLICATION command is executed, all entries in
> > RelationSyncCache
> > > will be discarded anyway. This mechanism works well but is sometimes
> > > not
> > efficient.
> > > For example, when the ALTER P
Dear Amit,
> > When the ALTER PUBLICATION command is executed, all entries in
> RelationSyncCache
> > will be discarded anyway. This mechanism works well but is sometimes not
> efficient.
> > For example, when the ALTER PUBLICATION DROP TABLE is executed,
> > 1) the specific entry in RelationSyncC
On Mon, Mar 3, 2025 at 1:27 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Hi, this is a fork thread from [1]. I want to propose a small optimization for
> logical replication system.
>
> Background
> ==
>
> When the ALTER PUBLICATION command is executed, all entries in
> RelationSyncCache
> will
Dear hackers,
Hi, this is a fork thread from [1]. I want to propose a small optimization for
logical replication system.
Background
==
When the ALTER PUBLICATION command is executed, all entries in RelationSyncCache
will be discarded anyway. This mechanism works well but is sometimes not
28 matches
Mail list logo
