On Mon, Jul 24, 2023 at 9:32 PM Tomas Vondra
<tomas.vondra@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.oss@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.