Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
От | Amit Kapila |
---|---|
Тема | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |
Дата | |
Msg-id | CAA4eK1Ku93J=9cdZnrjAHwgez5VN2vHWwQ=gUJ+eDJn6ViQ4hw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
|
Список | pgsql-hackers |
On Fri, Jul 10, 2020 at 3:37 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Sat, Jul 4, 2020 at 11:35 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > 8. We can't stream the transaction before we reach the > > SNAPBUILD_CONSISTENT state because some other output plugin can apply > > those changes unlike what we do with pgoutput plugin (which writes to > > file). And, I think applying the transactions without reaching a > > consistent state would be anyway wrong. So, we should avoid that and > > if do that then we should have an Assert for streamed txns rather than > > sending abort for them in ReorderBufferForget. > > I was analyzing this point so currently, we only enable streaming in > StartReplicationSlot so basically in CreateReplicationSlot the > streaming will be always off because by that time plugins are not yet > startup that will happen only on StartReplicationSlot. > What do you mean by 'startup' in the above sentence? AFAICS, we do call startup_cb_wrapper in CreateInitDecodingContext which is called from both CreateReplicationSlot and create_logical_replication_slot before the start of decoding. In CreateInitDecodingContext, we call StartupDecodingContext which should load the plugin. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: