Re: logical decoding and replication of sequences, take 2
От | Amit Kapila |
---|---|
Тема | Re: logical decoding and replication of sequences, take 2 |
Дата | |
Msg-id | CAA4eK1Lv8C+mtgp9e=CGZYM3ExN_9eN0u4aHsJcRbJPnjRWcwQ@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
|
Список | pgsql-hackers |
On Sun, Dec 3, 2023 at 11:56 PM Tomas Vondra <tomas.vondra@enterprisedb.com> wrote: > > On 12/3/23 18:52, Tomas Vondra wrote: > > ... > > > > Another idea is that maybe we could somehow inform ReorderBuffer whether > the output plugin even is interested in sequences. That'd help with > cases where we don't even want/need to replicate sequences, e.g. because > the publication does not specify (publish=sequence). > > What happens now in that case is we call ReorderBufferQueueSequence(), > it does the whole dance with starting/aborting the transaction, calls > rb->sequence() which just does "meh" and doesn't do anything. Maybe we > could just short-circuit this by asking the output plugin somehow. > > In an extreme case the plugin may not even specify the sequence > callbacks, and we're still doing all of this. > We could explore this but I guess it won't solve the problem we are facing in cases where all sequences are published and plugin has specified the sequence callbacks. I think it would add some overhead of this check in positive cases where we decide to anyway do send the changes. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: