Re: logical decoding and replication of sequences, take 2
От | Ashutosh Bapat |
---|---|
Тема | Re: logical decoding and replication of sequences, take 2 |
Дата | |
Msg-id | CAExHW5vqbFg+C9h3F4Q7L6S0Rjur5TRNX7bgpB6D_a8wfDNHVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: logical decoding and replication of sequences, take 2 (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: logical decoding and replication of sequences, take 2
Re: logical decoding and replication of sequences, take 2 |
Список | pgsql-hackers |
On Wed, Aug 16, 2023 at 7:56 PM Tomas Vondra <tomas.vondra@enterprisedb.com> wrote: > > > > > But whether or not that's the case, downstream should not request (and > > hence receive) any changes that have been already applied (and > > committed) downstream as a principle. I think a way to achieve this is > > to update the replorigin_session_origin_lsn so that a sequence change > > applied once is not requested (and hence sent) again. > > > > I guess we could update the origin, per attached 0004. We don't have > timestamp to set replorigin_session_origin_timestamp, but it seems we > don't need that. > > The attached patch merges the earlier improvements, except for the part > that experimented with adding a "fake" transaction (which turned out to > have a number of difficult issues). 0004 looks good to me. But I need to review the impact of not setting replorigin_session_origin_timestamp. What fake transaction experiment are you talking about? -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: