Hi Hackers,
Various sections of the code utilize the walrcv_connect() function,
employed by various processes such as walreceiver, logical replication
apply worker, etc., to establish connections with other hosts.
Presently, in case of connection failures, the error message lacks
information about
Thanks for the review. Attached v2 patch with suggested changes.
Please find my response inline.
On Fri, Jan 12, 2024 at 8:20 AM Peter Smith wrote:
>
> Thanks for the patch! Here are a couple of review comments for it.
>
> ==
> src/backend/commands/subscriptioncmds.c
>
> 1.
> @@ -742,7 +742,7
Thanks for reviewing, please find my response inline.
On Wed, Jan 17, 2024 at 4:56 AM Peter Smith wrote:
>
> On Sat, Jan 13, 2024 at 12:36 AM Aleksander Alekseev
> wrote:
> >
> > Hi,
> >
> > Thanks for the patch.
> >
> > > Due to this behavior, it is not possible to add a test to show the
> > >
A review on v62-006: failover-ready validation steps doc -
+ Next, check that the logical replication slots identified above exist on
+ the standby server. This step can be skipped if
+ standby_slot_names has been correctly configured.
+
+test_standby=# SELECT bool_and(synced AND
>
> ~~
>
> BTW, while experimenting with the bad connection ALTER I also tried
> setting 'disable_on_error' like below:
>
> ALTER SUBSCRIPTION sub4 SET (disable_on_error);
> ALTER SUBSCRIPTION sub4 CONNECTION 'port = -1';
>
> ...but here the subscription did not become DISABLED as I expected it
> w
On Fri, Jan 12, 2024 at 7:06 PM Aleksander Alekseev
wrote:
>
> Hi,
>
> Thanks for the patch.
>
> > Due to this behavior, it is not possible to add a test to show the
> > error message as it is done for CREATE SUBSCRIPTION.
> > Let me know if you think there is another way to add this test.
>
> I b
> AFAIK some recent commits patches (e,g [1] for the "slot sync"
> development) have created some more cases of "could not connect..."
> messages. So, you might need to enhance your patch to deal with any
> new ones in the latest HEAD.
>
> ==
> [1]
> https://github.com/postgres/postgres/commit
We conducted stress testing for the patch with a setup of one primary
node with 100 tables and five subscribers, each having 20
subscriptions. Then created three physical standbys syncing the
logical replication slots from the primary node.
All 100 slots were successfully synced on all three standb
On Wed, Mar 13, 2024 at 11:16 AM Peter Smith wrote:
>
> FYI -- some more code has been pushed since this patch was last
> updated. AFAICT perhaps you'll want to update this patch again for the
> following new connection messages on HEAD:
>
> - slotfuncs.c [1]
> - slotsync.c [2]
>
> --
> [1
Did performance test on optimization patch
(v2-0001-optimize-the-slot-advancement.patch). Please find the
results:
Setup:
- One primary node with 100 failover-enabled logical slots
- 20 DBs, each having 5 failover-enabled logical replication slots
- One physical standby node with 'sync_replica
I did performance tests for the v99 patch w.r.t. wait time analysis.
As this patch is introducing a wait for standby before sending changes
to a subscriber, at the primary node, logged time at the start and end
of the XLogSendLogical() call (which eventually calls
WalSndWaitForWal()) and calculated
uot;"D:/Project/pg1/postgres/tmp_install/bin/pg_dump" -V"
check for "D:/Project/pg1/postgres/tmp_install/bin/pg_dump" failed:
cannot execute
Failure, exiting
[16:08:50.444](7.434s) not ok 10 - run of pg_upgrade of old cluster
Has anyone come across this issue? I am not sure what is the issue here.
Any thoughts?
Thanks,
Nisha Moond
regress_log_003_logical_slots
Description: Binary data
(feof(pgver))
fprintf(stderr, "no data was returned by command \"%s\"\n", cmd);
…
…
And the log looks like -
cmd output - postgres (PostgreSQL) 17devel
no data was returned by command
""D:/Project/pg1/postgres/tmp_install/bin/pg_controldata" -V"
check for "D:/Project/pg1/postgres/tmp_install/bin/pg_controldata"
failed: cannot execute
Failure, exiting
Attached test result log for the same - "regress_log_003_logical_slots".
Thanks,
Nisha Moond
regress_log_003_logical_slots
Description: Binary data
On Fri, Nov 3, 2023 at 5:02 PM Nisha Moond wrote:
>
> On Thu, Nov 2, 2023 at 11:52 AM Kyotaro Horiguchi
> wrote:
> >
> > At Tue, 31 Oct 2023 18:11:48 +0530, vignesh C wrote in
> > > Few others are also facing this problem with similar code like in:
> > &
Review for v41 patch.
1.
==
src/backend/utils/misc/postgresql.conf.sample
+#enable_syncslot = on # enables slot synchronization on the physical
standby from the primary
enable_syncslot is disabled by default, so, it should be 'off' here.
~~~
2.
IIUC, the slotsyncworker's connection to the p
On Fri, Dec 1, 2023 at 5:40 PM Nisha Moond wrote:
>
> Review for v41 patch.
>
> 1.
> ==
> src/backend/utils/misc/postgresql.conf.sample
>
> +#enable_syncslot = on # enables slot synchronization on the physical
> standby from the primary
>
> enable_syncsl
A review on v45 patch:
If one creates a logical slot with failover=true as -
select pg_create_logical_replication_slot('logical_slot','pgoutput',
false, true, true);
Then, uses the existing logical slot while creating a subscription -
postgres=# create subscription sub4 connection 'dbname=postgr
Review for v47 patch -
(1)
When we try to create a subscription on standby using a synced slot
that is in 'r' sync_state, the subscription will be created at the
subscriber, and on standby, two actions will take place -
(i) As copy_data is true by default, it will switch the failover
state of
Thanks for working on it. I tested the patch on my system and it
resolved the issue with commands running -V (version check).
As you mentioned, I am also still seeing intermittent errors even with
the patch as below -
in 'pg_upgrade/002_pg_upgrade' -
# Running: pg_upgrade --no-sync -d
D:\Project
On Wed, Jun 5, 2024 at 7:29 PM Dilip Kumar wrote:
>
> On Tue, Jun 4, 2024 at 9:37 AM Amit Kapila wrote:
> >
> > Can you share the use case of "earliest_timestamp_wins" resolution
> > method? It seems after the initial update on the local node, it will
> > never allow remote update to succeed whic
On Mon, Jun 24, 2024 at 7:39 AM Zhijie Hou (Fujitsu)
wrote:
>
> When testing the patch, I noticed a bug that when reporting the conflict
> after calling ExecInsertIndexTuples(), we might find the tuple that we
> just inserted and report it.(we should only report conflict if there are
> other confl
On Mon, Jul 1, 2024 at 1:17 PM Ajin Cherian wrote:
>
>
>
> On Thu, Jun 27, 2024 at 1:14 PM Nisha Moond wrote:
>>
>> Please find the attached 'patch0003', which implements conflict
>> resolutions according to the global resolver settings.
>>
>
On Tue, Jul 9, 2024 at 1:00 AM Tom Lane wrote:
>
> Nisha Moond writes:
> > Attached v5 patch with the translator comments as suggested.
>
> I looked at this, and I agree with the goal, but I find just about all
> of the translator comments unnecessary. The ones that are use
On Mon, May 27, 2024 at 11:19 AM shveta malik wrote:
>
> On Sat, May 25, 2024 at 2:39 AM Tomas Vondra
> wrote:
> >
> > On 5/23/24 08:36, shveta malik wrote:
> > > Hello hackers,
> > >
> > > Please find the proposal for Conflict Detection and Resolution (CDR)
> > > for Logical replication.
> > >
On Fri, Apr 26, 2024 at 1:10 PM Daniel Gustafsson wrote:
>
> > On 22 Mar 2024, at 11:42, Nisha Moond wrote:
>
> > Here is the v4 patch with changes required in slotfuncs.c and slotsync.c
> > files.
>
> - errmsg("could not connect to the primary server:
On Thu, Aug 22, 2024 at 3:45 PM shveta malik wrote:
>
> On Wed, Aug 21, 2024 at 4:08 PM Nisha Moond wrote:
> >
> > The patches have been rebased on the latest pgHead following the merge
> > of the conflict detection patch [1].
>
> Thanks for working on patches.
&g
On Mon, Aug 26, 2024 at 9:05 AM shveta malik wrote:
>
> On Wed, Aug 21, 2024 at 4:08 PM Nisha Moond wrote:
> >
> > The patches have been rebased on the latest pgHead following the merge
> > of the conflict detection patch [1]. The detect_conflict option has
> &
On Mon, Aug 26, 2024 at 2:23 PM Amit Kapila wrote:
>
> On Thu, Aug 22, 2024 at 3:45 PM shveta malik wrote:
> >
> > On Wed, Aug 21, 2024 at 4:08 PM Nisha Moond
> > wrote:
> > >
> > > The patches have been rebased on the latest pgHead following the merg
On Fri, Aug 23, 2024 at 10:39 AM shveta malik wrote:
>
> On Thu, Aug 22, 2024 at 3:44 PM shveta malik wrote:
> >
> >
> > For clock-skew and timestamp based resolution, if needed, I will post
> > another email for the design items where suggestions are needed.
> >
>
> Please find issues which need
On Fri, Aug 23, 2024 at 10:39 AM shveta malik wrote:
>
> On Thu, Aug 22, 2024 at 3:44 PM shveta malik wrote:
> >
> >
> > For clock-skew and timestamp based resolution, if needed, I will post
> > another email for the design items where suggestions are needed.
> >
>
> Please find issues which need
On Mon, Aug 26, 2024 at 2:23 PM Amit Kapila wrote:
>
> On Thu, Aug 22, 2024 at 3:45 PM shveta malik wrote:
> >
> > On Wed, Aug 21, 2024 at 4:08 PM Nisha Moond
> > wrote:
> > >
> > > The patches have been rebased on the latest pgHead following the merg
On Thu, Aug 29, 2024 at 4:43 PM Amit Kapila wrote:
>
> On Fri, Aug 23, 2024 at 10:39 AM shveta malik wrote:
> >
> > Please find issues which need some thoughts and approval for
> > time-based resolution and clock-skew.
> >
> > 1)
> > Time based conflict resolution and two phase transactions:
> >
On Wed, Sep 4, 2024 at 12:23 PM shveta malik wrote:
>
> Hello hackers,
> (Cc people involved in the earlier discussion)
>
> I would like to discuss the $Subject.
>
> While discussing Logical Replication's Conflict Detection and
> Resolution (CDR) design in [1] , it came to our notice that the
> c
On Fri, Sep 6, 2024 at 2:05 PM Ajin Cherian wrote:
>
>
>
> On Thu, Aug 29, 2024 at 2:50 PM shveta malik wrote:
>>
>> On Wed, Aug 28, 2024 at 4:07 PM shveta malik wrote:
>> >
>> > > On Wed, Aug 28, 2024 at 10:30 AM Ajin Cherian wrote:
>> > > >
>> >
>> > The review is WIP. Please find a few comme
On Thu, Jul 18, 2024 at 7:52 AM Zhijie Hou (Fujitsu)
wrote:
>
> Attach the V5 patch set which changed the following:
>
Tested v5-0001 patch, and it fails to detect the update_exists
conflict for a setup where Pub has a non-partitioned table and Sub has
the same table partitioned.
Below is a testc
On Thu, Jul 25, 2024 at 12:04 PM Zhijie Hou (Fujitsu)
wrote:
> Here is the V6 patch set which addressed Shveta and Nisha's comments
> in [1][2][3][4].
Thanks for the patch.
I tested the v6-0001 patch with partition table scenarios. Please
review the following scenario where Pub updates a tuple, c
Performance tests done on the v8-0001 and v8-0002 patches, available at [1].
The purpose of the performance tests is to measure the impact on
logical replication with track_commit_timestamp enabled, as this
involves fetching the commit_ts data to determine
delete_differ/update_differ conflicts.
F
On Mon, Aug 5, 2024 at 10:05 AM shveta malik wrote:
>
> On Mon, Aug 5, 2024 at 9:19 AM Amit Kapila wrote:
> >
> > On Fri, Aug 2, 2024 at 6:28 PM Nisha Moond wrote:
> > >
> > > Performance tests done on the v8-0001 and v8-0002 patches, available at
> >
On Tue, Oct 1, 2024 at 9:48 AM shveta malik wrote:
>
> On Mon, Sep 30, 2024 at 2:55 PM Peter Smith wrote:
> >
> > On Mon, Sep 30, 2024 at 4:29 PM shveta malik wrote:
> > >
> > > On Mon, Sep 30, 2024 at 11:04 AM Peter Smith
> > > wrote:
> > > >
> > > > On Mon, Sep 30, 2024 at 2:27 PM shveta mal
On Mon, Sep 30, 2024 at 11:59 AM shveta malik wrote:
>
> On Mon, Sep 30, 2024 at 11:04 AM Peter Smith wrote:
> >
> > On Mon, Sep 30, 2024 at 2:27 PM shveta malik wrote:
> > >
> > > On Fri, Sep 27, 2024 at 1:00 PM Peter Smith wrote:
> > ...
> > > >
> > > > 13. General - ordering of conflict_type
On Fri, Sep 27, 2024 at 1:00 PM Peter Smith wrote:
>
> Here are some review comments for v14-0001.
> ~~~
> 7.
> +ALTER SUBSCRIPTION name
> RESET CONFLICT RESOLVER FOR ( class="parameter">conflict_type)
>
> I can see that this matches the implementation, but I was wondering
> why don't you permit r
On Wed, Sep 18, 2024 at 3:31 PM shveta malik wrote:
>
> On Wed, Sep 18, 2024 at 2:49 PM shveta malik wrote:
> >
> > > > Please find the attached v46 patch having changes for the above review
> > > > comments and your test review comments and Shveta's review comments.
> > > >
>
> When the synced s
On Wed, Sep 18, 2024 at 12:22 PM shveta malik wrote:
>
> On Mon, Sep 16, 2024 at 3:31 PM Bharath Rupireddy
> wrote:
> >
> > Hi,
> >
> >
> > Please find the attached v46 patch having changes for the above review
> > comments and your test review comments and Shveta's review comments.
> >
>
> Thank
Please find the v48 patch attached.
On Thu, Sep 19, 2024 at 9:40 AM shveta malik wrote:
>
> When we promote hot standby with synced logical slots to become new
> primary, the logical slots are never invalidated with
> 'inactive_timeout' on new primary. It seems the check in
> SlotInactiveTimeout
On Fri, Sep 20, 2024 at 7:51 PM Tom Lane wrote:
>
> Nisha Moond writes:
> > While considering the implementation of timestamp-based conflict
> > resolution (last_update_wins) in logical replication (see [1]), there
> > was a feedback at [2] and the discussion on
On Mon, Sep 23, 2024 at 4:00 PM Nisha Moond wrote:
>
> On Fri, Sep 20, 2024 at 7:51 PM Tom Lane wrote:
> >
> > Nisha Moond writes:
> > > While considering the implementation of timestamp-based conflict
> > > resolution (last_update_wins) in logical repl
On Fri, Sep 20, 2024 at 8:40 AM Nisha Moond wrote:
>
> On Wed, Sep 18, 2024 at 10:46 AM vignesh C wrote:
> >
> > On Thu, 12 Sept 2024 at 14:03, Ajin Cherian wrote:
> > >
> > > On Tue, Sep 3, 2024 at 7:42 PM vignesh C wrote:
> > >
> &
On Fri, Sep 20, 2024 at 8:40 AM Nisha Moond wrote:
>
> On Wed, Sep 18, 2024 at 10:46 AM vignesh C wrote:
> >
> > On Thu, 12 Sept 2024 at 14:03, Ajin Cherian wrote:
> > >
> > > On Tue, Sep 3, 2024 at 7:42 PM vignesh C wrote:
> > >
> &
Hello Hackers,
(CC people involved in the earlier discussion)
While considering the implementation of timestamp-based conflict
resolution (last_update_wins) in logical replication (see [1]), there
was a feedback at [2] and the discussion on whether or not to manage
clock-skew at database level. We
> Here is the V5 patch set which addressed above comments.
>
Here are a couple of comments on v5 patch-set -
1) In FindMostRecentlyDeletedTupleInfo(),
+ /* Try to find the tuple */
+ while (index_getnext_slot(scan, ForwardScanDirection, scanslot))
+ {
+ Assert(tuples_equal(scanslot, searchslot, e
On Mon, Sep 16, 2024 at 3:31 PM Bharath Rupireddy
wrote:
>
> Please find the attached v46 patch having changes for the above review
> comments and your test review comments and Shveta's review comments.
>
Hi,
I’ve reviewed this thread and am interested in working on the
remaining tasks and commen
On Thu, Nov 28, 2024 at 2:44 PM vignesh C wrote:
>
> >
> > We are setting inactive_since when the replication slot is released.
> > We are marking the slot as inactive only if it has been released.
> > However, there's a scenario where the network connection between the
> > publisher and subscribe
On Tue, Nov 19, 2024 at 12:47 PM Nisha Moond wrote:
>
> On Thu, Nov 14, 2024 at 5:29 AM Peter Smith wrote:
> >
> >
> > 12.
> > /*
> > - * If the slot can be acquired, do so and mark it invalidated
> > - * immediately. Otherwise we'll sign
On Thu, Nov 28, 2024 at 1:29 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Nisha,
>
> >
> > Attached v51 patch-set addressing all comments in [1] and [2].
> >
>
> Thanks for working on the feature! I've stated to review the patch.
> Here are my comments - sorry if there are something which have alrea
On Thu, Nov 28, 2024 at 5:20 AM Peter Smith wrote:
>
> Hi Nisha. Here are some review comments for patch v51-0002.
>
> ==
> src/backend/replication/slot.c
>
> ReplicationSlotAcquire:
>
> 2.
> GENERAL.
>
> This just is a question/idea. It may not be feasible to change. It
> seems like there is
Attached is the v49 patch set:
- Fixed the bug reported in [1].
- Addressed comments in [2] and [3].
I've split the patch into two, implementing the suggested idea in
comment #5 of [2] separately in 001:
Patch-001: Adds additional error reports (for all invalidation types)
in ReplicationSlotAcqui
On Thu, Nov 14, 2024 at 5:29 AM Peter Smith wrote:
>
> Hi Nisha.
>
> Thanks for the recent patch updates. Here are my review comments for
> the latest patch v48-0001.
>
Thank you for the review. Comments are addressed in v49 version.
Below is my response to comments that may require further discu
On Thu, Nov 14, 2024 at 9:14 AM vignesh C wrote:
>
> On Wed, 13 Nov 2024 at 15:00, Nisha Moond wrote:
> >
> > Please find the v48 patch attached.
> >
> > On Thu, Sep 19, 2024 at 9:40 AM shveta malik wrote:
> > >
> > > When we promote hot
On Fri, Nov 15, 2024 at 3:01 PM Amit Kapila wrote:
>
> On Thu, Nov 14, 2024 at 12:12 PM Nisha Moond wrote:
> >
> > On Thu, Oct 31, 2024 at 11:05 PM Bruce Momjian wrote:
> > >
> > >
> > > Yes, all good suggestions, updated patch attached.
>
On Thu, Nov 14, 2024 at 8:24 AM Zhijie Hou (Fujitsu)
wrote:
>
> Attach the V9 patch set which addressed above comments.
>
Reviewed v9 patch-set and here are my comments for below changes:
@@ -1175,10 +1189,29 @@ ApplyLauncherMain(Datum main_arg)
long elapsed;
if (!sub->enabled)
+ {
+ can_ad
On Wed, Nov 27, 2024 at 8:39 AM Peter Smith wrote:
>
> Hi Nisha,
>
> Here are some review comments for the patch v50-0002.
>
> ==
> src/backend/replication/slot.c
>
> InvalidatePossiblyObsoleteSlot:
>
> 1.
> + if (now &&
> + TimestampDifferenceExceeds(s->inactive_since, now,
> +replication
On Thu, Oct 31, 2024 at 11:05 PM Bruce Momjian wrote:
>
>
> Yes, all good suggestions, updated patch attached.
>
Few comments for the changes under "inactive_since" description:
+The time when slot synchronization (see )
+was most recently stopped. NULL if the slot
+has
M79f34LLBGq4UeRuZ1URWP6JNZtdN2khYPrLc1YqrQ%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/TYAPR01MB5692B7687EE7981AA91BA5B9F5362%40TYAPR01MB5692.jpnprd01.prod.outlook.com
--
Thanks,
Nisha
From b7e55950ae7577dfc8ae8893157d6b6124fdba01 Mon Sep 17 00:00:00 2001
From: Nisha Moond
Date: Mon, 18 N
On Mon, Jan 6, 2025 at 4:52 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Friday, January 3, 2025 2:36 PM Masahiko Sawada
> wrote:
>
> Hi,
>
> >
> > I have one comment on the 0001 patch:
>
> Thanks for the comments!
>
> >
> > + /*
> > +* The changes made by this and later transactions are
On Mon, Dec 30, 2024 at 11:05 AM Peter Smith wrote:
>
> On Tue, Dec 24, 2024 at 10:37 PM Nisha Moond wrote:
> >
> > On Fri, Dec 20, 2024 at 3:12 PM Amit Kapila wrote:
> >>
> >> On Mon, Dec 16, 2024 at 4:10 PM Nisha Moond
> >> wrote:
> >
On Fri, Dec 27, 2024 at 9:22 AM vignesh C wrote:
>
>
> Few comments:
> 1) We have disabled the similar configuration max_slot_wal_keep_size
> by setting to -1, as this GUC also is in similar lines, should we
> disable this and let the user configure it?
> +/*
> + * Invalidate replication slots tha
On Tue, Jan 7, 2025 at 6:04 PM Zhijie Hou (Fujitsu)
wrote:
>
>
> Attached the V19 patch which addressed comments in [1][2][3][4][5][6][7].
>
Here are a couple of initial review comments on v19 patch set:
1) The subscription option 'retain_conflict_info' remains set to
"true" for a subscription e
On Fri, Dec 20, 2024 at 3:12 PM Amit Kapila wrote:
> On Mon, Dec 16, 2024 at 4:10 PM Nisha Moond
> wrote:
> >
> > Here is the v56 patch set with the above comments incorporated.
> >
>
> Review comments:
> ===
> 1.
> + {
> + {&
from [1] and [2].
- No change in patch-003 since the last version.
[1]
https://www.postgresql.org/message-id/CALDaNm0FS%2BFqQk2dadiJFCMM_MhKROMsJUb%3Db8wtRH6isScQsQ%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAHut%2BPs_6%2BNBOt%2BKpQQaBG2R3T-FLS93TbUC27uzyDMu%3D37n-Q%40mail.gmail.com
--
Thanks,
Ni
On Mon, Feb 3, 2025 at 2:55 PM Amit Kapila wrote:
>
> On Fri, Jan 31, 2025 at 5:50 PM Nisha Moond wrote:
> >
> > Please find the attached v66 patch set. The base patch(v65-001) is
> > committed now, so I have rebased the patches.
> >
>
> *
>
&
Hi Hackers,
(CC people involved in the earlier discussion)
Right now, it is possible for the 'inactive_since' value of an invalid
replication slot to be updated multiple times, which is unexpected
behavior.
As suggested in the ongoing thread [1], this patch introduces a new
dedicated function to u
On Tue, Feb 4, 2025 at 4:42 PM vignesh C wrote:
>
> On Tue, 4 Feb 2025 at 15:58, Nisha Moond wrote:
> >
> > Here are the v68 patches, incorporating above as well as comments from [1].
> >
> Few comments:
> 1) Let's call Timest
On Tue, Feb 4, 2025 at 9:33 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Monday, February 3, 2025 8:03 PM Nisha Moond
> wrote:
> >
> > Hi Hackers,
> > (CC people involved in the earlier discussion)
> >
> > Right now, it is possible for the 'inactive_since&#x
On Tue, Feb 4, 2025 at 10:45 AM Amit Kapila wrote:
>
> On Mon, Feb 3, 2025 at 6:35 PM Shlok Kyal wrote:
> >
> > I reviewed the v66 patch. I have few comments:
> >
> > 1. I also feel the default value should be set to '0' as suggested by
> > Vignesh in 1st point of [1].
> >
>
> +1. This will ensur
On Thu, Feb 6, 2025 at 10:17 AM Amit Kapila wrote:
>
> On Thu, Feb 6, 2025 at 8:02 AM Nisha Moond wrote:
> >
> > On Wed, Feb 5, 2025 at 2:42 PM Amit Kapila wrote:
> > >
> > > Would it address your concern if we write the actual idle duration
> > &g
On Mon, Feb 10, 2025 at 6:12 PM vignesh C wrote:
>
> On Mon, 10 Feb 2025 at 17:33, Nisha Moond wrote:
> >
> > Here are the v73 patches incorporating the comments above and the
> > subsequent comments from [1].
> > - patch 002 is rebased on 001 with no new chang
On Sat, Feb 8, 2025 at 12:28 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Friday, February 7, 2025 9:06 PM Nisha Moond
> wrote:
> >
> > Attached v72 patches, addressed the above comments as well as Vignesh's
> > comments in [2].
> > - There are no new changes in
On Wed, Feb 5, 2025 at 10:30 AM vignesh C wrote:
>
> On Tue, 4 Feb 2025 at 19:56, Nisha Moond wrote:
> >
> > Here is v69 patch set addressing above and Kuroda-san's comments in [1].
>
> 2) Here we have mentioned about invalidation happens only for a)
>
On Wed, Feb 5, 2025 at 12:58 PM Peter Smith wrote:
>
> Hi Nisha,
>
> Some review comments for the patch v69-0002.
>
> ==
> .../t/044_invalidate_inactive_slots.pl
>
> 2.
> +if ($ENV{enable_injection_points} ne 'yes')
> +{
> + plan skip_all => 'Injection points not supported by this build';
> +}
On Wed, Feb 5, 2025 at 2:42 PM Amit Kapila wrote:
>
> On Wed, Feb 5, 2025 at 10:30 AM vignesh C wrote:
> >
> > On Tue, 4 Feb 2025 at 19:56, Nisha Moond wrote:
> > >
> > > Here is v69 patch set addressing above and Kuroda-san's comments in [1].
> >
On Fri, Feb 7, 2025 at 8:00 AM Peter Smith wrote:
>
> Hi Nisha,
>
> Some review comments for v71-0001.
>
> ==
> src/backend/replication/slot.c
>
> SlotInvalidationCauses[]
>
> 2.
> [RS_INVAL_WAL_REMOVED] = "wal_removed",
> [RS_INVAL_HORIZON] = "rows_removed",
> [RS_INVAL_WAL_LEVEL] = "wa
On Tue, Feb 11, 2025 at 11:42 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Monday, February 10, 2025 8:03 PM Nisha Moond
> wrote:
> >
> > On Sat, Feb 8, 2025 at 12:28 PM Zhijie Hou (Fujitsu)
> >
> > wrote:
> > >
> >
> > > 3.
> &g
On Tue, Feb 11, 2025 at 8:49 AM Peter Smith wrote:
>
> Hi Nisha.
>
> Some review comments about v74-0001
>
> ==
> src/backend/replication/slot.c
>
> 1.
> /* Maximum number of invalidation causes */
> -#define RS_INVAL_MAX_CAUSES RS_INVAL_WAL_LEVEL
> -
> -StaticAssertDecl(lengthof(SlotInvalida
On Tue, Jan 28, 2025 at 5:28 PM Nisha Moond wrote:
>
> On Tue, Jan 28, 2025 at 3:26 PM Amit Kapila wrote:
> >
> > On Mon, Dec 30, 2024 at 11:05 AM Peter Smith wrote:
> > >
> > > I think we are often too quick to throw out perfectly good tests.
> >
On Fri, Jan 31, 2025 at 2:32 PM Amit Kapila wrote:
>
> On Fri, Jan 31, 2025 at 10:40 AM Peter Smith wrote:
> >
> > ==
> > src/backend/replication/slot.c
> >
> > ReportSlotInvalidation:
> >
> > 1.
> > +
> > + case RS_INVAL_IDLE_TIMEOUT:
> > + Assert(inactive_since > 0);
> > + /* translator: se
Here are the test steps and analysis for epoch-related handling
(Tested with v15 Patch-Set).
In the 'update_deleted' detection design, the launcher process
compares XIDs to track minimum XIDs, and the apply workers maintain
the oldest running XIDs. The launcher also requests publisher status
at re
2Ct39yg%40mail.gmail.com
[3]
https://www.postgresql.org/message-id/CAHut%2BPtHbYNxPvtMfs7jARbsVcFXL1%3DC9SO3Q93NgVDgbKN7LQ%40mail.gmail.com
--
Thanks,
Nisha
From 713871d8cda02f2b70c63983fc49dede3097f016 Mon Sep 17 00:00:00 2001
From: Nisha Moond
Date: Mon, 18 Nov 2024 16:13:26 +0530
Subject: [PATCH v54
On Mon, Dec 16, 2024 at 9:58 AM Peter Smith wrote:
>
> Hi Nisha.
>
> Thanks for the v55* patches.
>
> I have no comments for patch v55-0001.
>
> I have only 1 comment for patch v55-0002 regarding some remaining
> nitpicks (below) about the consistency of phrases.
>
> ==
>
> SUGGESTIONS:
>
> Do
On Wed, Dec 11, 2024 at 8:14 AM Peter Smith wrote:
>
> Hi Nisha.
>
> Here are some review comments for patch v54-0002.
> ==
> src/test/recovery/t/043_invalidate_inactive_slots.pl
>
> 5.
> +# Wait for slot to first become idle and then get invalidated
> +sub wait_for_slot_invalidation
> +{
> +
On Thu, Dec 12, 2024 at 9:42 AM vignesh C wrote:
>
>
> Now that we support idle_replication_slot_timeout in milliseconds, we
> can set this value from 1s to 1ms or 10millseconds and change sleep to
> usleep, this will bring down the test execution time significantly:
+1
v55 implements the test us
Here is further performance test analysis with v16 patch-set.
In the test scenarios already shared on -hackers [1], where pgbench was run
only on the publisher node in a pub-sub setup, no performance degradation
was observed on either node.
In contrast, when pgbench was run only on the subscri
On Wed, Nov 20, 2024 at 1:29 PM vignesh C wrote:
>
> On Tue, 19 Nov 2024 at 12:43, Nisha Moond wrote:
> >
> > Attached is the v49 patch set:
> > - Fixed the bug reported in [1].
> > - Addressed comments in [2] and [3].
> >
> > I've split the pat
On Wed, Jan 8, 2025 at 3:02 PM Masahiko Sawada wrote:
>
> On Thu, Dec 19, 2024 at 11:11 PM Nisha Moond wrote:
> > [3] Test with pgbench run on both publisher and subscriber.
> >
> > Test setup:
> > - Tests performed on pgHead + v16 patches
> > -
On Sat, Jan 18, 2025 at 9:15 AM Zhijie Hou (Fujitsu)
wrote:
>
>
> Here is the V24 patch set. I modified 0004 patch to implement the slot
> Invalidation part. Since the automatic recovery could be an optimization and
> the discussion is in progress, I didn't implement that part.
Few comments for p
On Wed, Jan 8, 2025 at 4:03 PM Masahiko Sawada wrote:
>
> On Wed, Jan 8, 2025 at 1:53 AM Amit Kapila wrote:
> > On Wed, Jan 8, 2025 at 3:02 PM Masahiko Sawada
> > wrote:
> > > On Thu, Dec 19, 2024 at 11:11 PM Nisha Moond
> > > wrote:
> > > > He
On Fri, Jan 17, 2025 at 6:50 PM Shlok Kyal wrote:
>
> Hi Nisha,
>
> Thanks for providing an updated patch. I have tested the patch and ran
> some tests. The patch works fine. I have few comments:
>
Thanks for your review. Attached are the v61 patches.
I've addressed the comments and rebased patc
On Wed, Jan 22, 2025 at 10:49 AM Nisha Moond wrote:
>
> On Tue, Jan 21, 2025 at 8:22 AM Peter Smith wrote:
> >
> > Some review comments for patch v61-0001.
> >
> > ==
> > src/backend/replication/slot.c
> >
> > 2.
> > + /*
> > + * T
On Mon, Jan 27, 2025 at 4:20 PM Amit Kapila wrote:
>
> On Mon, Jan 27, 2025 at 11:00 AM Nisha Moond wrote:
> >
> > I discussed the above comments further with Peter off-list, and here
> > are the v63 patches with the following changes:
> > patch-001: The Assert
On Tue, Jan 28, 2025 at 3:26 PM Amit Kapila wrote:
>
> On Mon, Dec 30, 2024 at 11:05 AM Peter Smith wrote:
> >
> > I think we are often too quick to throw out perfectly good tests.
> > Citing that some similar GUCs don't do testing as a reason to skip
> > them just seems to me like an example of
Hello Hackers,
(CC people involved in the earlier discussion)
While implementing slot invalidation based on inactive(idle) timeout
(see [1]), several general optimizations and improvements were
identified.
This thread is a spin-off from [1], intended to address these
optimizations separately from
1 - 100 of 164 matches
Mail list logo
