On Wed, Jul 3, 2024 at 9:21 AM Hayato Kuroda (Fujitsu) <kuroda.hay...@fujitsu.com> wrote: > > Dear Amit, > > > IIUC, the problem is that the consistent_lsn value returned by > > setup_publisher() is the "end +1" location of the required LSN whereas > > the recovery_target_lsn used in wait_for_end_recovery() expects the > > LSN value to be "start" location of required LSN. > > Yeah, right. It is same as my understanding. > > > This sounds like an ugly hack to me and don't know if we can use it. > > I also think it is hacky, but I could not find better solutions. > > > The ideal way to fix this is to get the start_lsn from the > > create_logical_slot functionality or have some parameter like > > recover_target_end_lsn but I don't know if this is a good time to > > extend such a functionality. > > I felt that such approach might be used for HEAD, but not suitable for PG17. > Alternative approach I came up with was to insert a tuple while waiting the > promotion. It can generate a WAL record so that standby can finish after the > application. But I'm not sure how do we do and it seems to lead an additional > timing issue. Also, this does not improve the behavior of the command - normal > user may have to wait some time by the command. >
BTW, I think the time required by standby to reach a consistent state after startup is any way unpredictable. For example, if we consider that in real-world scenarios between the time we have stopped standby and restarted it, there could be many transactions on primary that need to be replicated before we reach recover_target_lsn. I don't think adding additional (dummy) WAL records is a good solution but it is better to hear from others. > Do you have any other idea? > The other idea could be that we use the minimum restart_lsn of all the slots created by this tool as a consistent_lsn. We can probably get that value by using pg_get_replication_slots() but this idea needs further evaluation as to whether it will lead to a consistent subscriber. -- With Regards, Amit Kapila.
