Re: logical decoding and replication of sequences, take 2
От | Ashutosh Bapat |
---|---|
Тема | Re: logical decoding and replication of sequences, take 2 |
Дата | |
Msg-id | CAExHW5scPcT_V-u=7f5FXXuAj6iujfLCQUVX5Oeyp1xwyORR7w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: logical decoding and replication of sequences, take 2 (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Список | pgsql-hackers |
On Thu, Aug 17, 2023 at 7:13 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote: > > > > 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. I think it will be good to set replorigin_session_origin_timestamp = 0 explicitly so as not to pick up a garbage value. The timestamp is written to the commit record. Beyond that I don't see any use of it. It is further passed downstream if there is cascaded logical replication setup. But I don't see it being used. So it should be fine to leave it 0. I don't think we can use logically replicated sequences in a mult-master environment where the timestamp may be used to resolve conflict. Such a setup will require a distributed sequence management which can not be achieved by logical replication alone. In short, I didn't find any hazard in leaving the replorigin_session_origin_timestamp as 0. -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: