RE: Synchronizing slots from primary to standby - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Synchronizing slots from primary to standby
Date
Msg-id TYAPR01MB586680D90A106DD5528829EFF5DDA@TYAPR01MB5866.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Synchronizing slots from primary to standby  (shveta malik <shveta.malik@gmail.com>)
Responses Re: Synchronizing slots from primary to standby
Re: Synchronizing slots from primary to standby
List pgsql-hackers
Dear Shveta,

> PFA v25 patch set. The changes are:

Thanks for making the patch! It seems that there are lots of comments, so
I can put some high-level comments for 0001.
Sorry if there are duplicated comments.

1.
The patch seemed not to consider the case that failover option between replication
slot and subscription were different. Currently slot option will be overwritten
by subscription one.

Actually, I'm not sure what specification is better. Regarding the two_phase,
2PC will be decoded only when the both of settings are true. Should we follow?

2.
Currently ctx->failover is set only in the pgoutput_startup(), but not sure it is OK.
Can we change the parameter in CreateDecodingContext() or similar functions?

Because IIUC it means that only slots which have pgoutput can wait. Other
output plugins must understand the change and set faliover flag as well -
I felt it is not good. E.g., you might miss to enable the parameter in test_decoding.

Regarding the two_phase parameter, setting on plugin layer is good because it
quite affects the output. As for the failover, it is not related with the
content so that all of slots should be enabled. 

I think CreateDecodingContext or StartupDecodingContext() is the common path.
Or, is it the out-of-scope for now?

Best Regards,
Hayato Kuroda
FUJITSU LIMITED


pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Re: RFC: Logging plan of the running query
Next
From: Rushabh Lathia
Date:
Subject: Parallel query behaving different with custom GUCs