On Mon, Jul 24, 2023 at 9:32 PM Tomas Vondra <tomas.von...@enterprisedb.com> wrote: > > On 7/24/23 12:40, Amit Kapila wrote: > > On Wed, Jul 5, 2023 at 8:21 PM Ashutosh Bapat > > <ashutosh.bapat....@gmail.com> wrote: > > > > Even after that, see below the value of the sequence is still not > > caught up. Later, when the apply worker processes all the WAL, the > > sequence state will be caught up. > > > > And how is this different from what tablesync does for tables? For that > 'r' also does not mean it's fully caught up, IIRC. What matters is > whether the sequence since this moment can go back. And I don't think it > can, because that would require replaying changes from before we did > copy_sequence ... >
For sequences, it is quite possible that we replay WAL from before the copy_sequence whereas the same is not true for tables (w.r.t copy_table()). This is because for tables we have a kind of interlock w.r.t LSN returned via create_slot (say this value of LSN is LSN1), basically, the walsender corresponding to tablesync worker in publisher won't send any WAL before that LSN whereas the same is not true for sequences. Also, even if apply worker can receive WAL before copy_table, it won't apply that as that would be behind the LSN1 and the same is not true for sequences. So, for tables, we will never go back to a state before the copy_table() but for sequences, we can go back to a state before copy_sequence(). -- With Regards, Amit Kapila.