Re: Synchronizing slots from primary to standby
| От | Ajin Cherian |
|---|---|
| Тема | Re: Synchronizing slots from primary to standby |
| Дата | |
| Msg-id | CAFPTHDZ6M8y9jTziE3YjOr_d_uttnDZhzTbUx=k5QjY=L5P3EA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Synchronizing slots from primary to standby (shveta malik <shveta.malik@gmail.com>) |
| Список | pgsql-hackers |
On Tue, Jan 30, 2024 at 11:53 PM shveta malik <shveta.malik@gmail.com> wrote:
On Tue, Jan 30, 2024 at 4:06 PM shveta malik <shveta.malik@gmail.com> wrote:
>
> PFA v73-0001 which addresses the above comments. Other patches will be
> rebased and posted after pushing this one.
Since v73-0001 is pushed, PFA rest of the patches. Changes are:
1) Rebased the patches.
2) Ran pg_indent on all.
3) patch001: Updated logicaldecoding.sgml for dbname requirement in
primary_conninfo for slot-synchronization.
thanks
Shveta
Just to test the behaviour, I modified the code to set failover flag to default to "true" while creating subscription and ran the regression tests. I only saw the expected errors.
1. Make check in postgres root folder - all failures are because of difference when listing subscription as failover flag is now enabled. The diff is attached for regress.
2. Make check in src/test/subscription - no failures All tests successful.
Files=34, Tests=457, 81 wallclock secs ( 0.14 usr 0.05 sys + 9.53 cusr 13.00 csys = 22.72 CPU)
Result: PASS
3. Make check in src/test/recovery - 3 failures Test Summary Report
-------------------
t/027_stream_regress.pl (Wstat: 256 Tests: 6 Failed: 1)
Failed test: 2
Non-zero exit status: 1
t/035_standby_logical_decoding.pl (Wstat: 7424 Tests: 8 Failed: 0)
Non-zero exit status: 29
Parse errors: No plan found in TAP output t/050_standby_failover_slots_sync.pl (Wstat: 7424 Tests: 5 Failed: 0)
Non-zero exit status: 29
Parse errors: No plan found in TAP output
3a. Analysis of t/027_stream_regress.pl - No, 027 fails with the same issue as "make check" in postgres root folder (for which I attached the diffs). 027 is about running the standard regression tests with streaming replication. Since the regression tests fail because listing subscription now has failover enabled, 027 also fails in the same way with streaming replication.
3b. Analysis of t/035_standby_logical_decoding.pl - In this test case, they attempt to create a subscription from the subscriber to the standby ##################################################
# Test that we can subscribe on the standby with the publication # created on the primary.
##################################################
Now, this fails because creating a subscription on the standby with failover enabled will result in error:
I see the following error in the log:
2024-01-28 23:51:30.425 EST [23332] tap_sub STATEMENT: CREATE_REPLICATION_SLOT "tap_sub" LOGICAL pgoutput (FAILOVER, SNAPSHOT 'nothing')
2024-01-28 23:51:30.425 EST [23332] tap_sub ERROR: cannot create replication slot with failover enabled on the standby I discussed this with Shveta and she agreed that this is the expected behaviour as we don't support failover to cascading standby yet.
3c. Analysis of t/050_standby_failover_slots_sync.pl - This is a new test case created for this patch, and it creates a subscription without failover enabled to make sure that the Subscription with failover disabled does not depend on sync on standby, but this fails because we have failover enabled by default.
In summary, I don't think these issues are actual bugs but expected behaviour change.
1. Make check in postgres root folder - all failures are because of difference when listing subscription as failover flag is now enabled. The diff is attached for regress.
2. Make check in src/test/subscription - no failures All tests successful.
Files=34, Tests=457, 81 wallclock secs ( 0.14 usr 0.05 sys + 9.53 cusr 13.00 csys = 22.72 CPU)
Result: PASS
3. Make check in src/test/recovery - 3 failures Test Summary Report
-------------------
t/027_stream_regress.pl (Wstat: 256 Tests: 6 Failed: 1)
Failed test: 2
Non-zero exit status: 1
t/035_standby_logical_decoding.pl (Wstat: 7424 Tests: 8 Failed: 0)
Non-zero exit status: 29
Parse errors: No plan found in TAP output t/050_standby_failover_slots_sync.pl (Wstat: 7424 Tests: 5 Failed: 0)
Non-zero exit status: 29
Parse errors: No plan found in TAP output
3a. Analysis of t/027_stream_regress.pl - No, 027 fails with the same issue as "make check" in postgres root folder (for which I attached the diffs). 027 is about running the standard regression tests with streaming replication. Since the regression tests fail because listing subscription now has failover enabled, 027 also fails in the same way with streaming replication.
3b. Analysis of t/035_standby_logical_decoding.pl - In this test case, they attempt to create a subscription from the subscriber to the standby ##################################################
# Test that we can subscribe on the standby with the publication # created on the primary.
##################################################
Now, this fails because creating a subscription on the standby with failover enabled will result in error:
I see the following error in the log:
2024-01-28 23:51:30.425 EST [23332] tap_sub STATEMENT: CREATE_REPLICATION_SLOT "tap_sub" LOGICAL pgoutput (FAILOVER, SNAPSHOT 'nothing')
2024-01-28 23:51:30.425 EST [23332] tap_sub ERROR: cannot create replication slot with failover enabled on the standby I discussed this with Shveta and she agreed that this is the expected behaviour as we don't support failover to cascading standby yet.
3c. Analysis of t/050_standby_failover_slots_sync.pl - This is a new test case created for this patch, and it creates a subscription without failover enabled to make sure that the Subscription with failover disabled does not depend on sync on standby, but this fails because we have failover enabled by default.
In summary, I don't think these issues are actual bugs but expected behaviour change.
regards,
Ajin Cherian
Fujitsu Australia
В списке pgsql-hackers по дате отправления: