Hi,
Thanks for all the work that has been done on this feature, and sorry
to have been quiet on it for so long.
On 9/18/23 12:22 PM, shveta malik wrote:
On Wed, Sep 13, 2023 at 4:48 PM Hayato Kuroda (Fujitsu)
<kuroda.hay...@fujitsu.com> wrote:
Right, but I wanted to know why it is needed. One motivation seemed to know the
WAL location of physical standby, but I thought that struct WalSnd.apply could
be also used. Is it bad to assume that the physical walsender always exists?
We do not plan to target this case where physical slot is not created
between primary and physical-standby in the first draft. In such a
case, slot-synchronization will be skipped for the time being. We can
extend this functionality (if needed) later.
I do think it's needed to extend this functionality. Having physical slot
created sounds like a (too?) strong requirement as:
- It has not been a requirement for Logical decoding on standby so that could
sounds weird
to require it for sync slot (while it's not allowed to logical decode from sync
slots)
- One could want to limit the WAL space used on the primary
It seems that the "skipping sync as primary_slot_name not set." warning message
is emitted
every 10ms, that seems too verbose to me.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
