Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Дата
Msg-id CAA4eK1L9=aCZDFS=Jc9CT_szUpcn1euWZ3ytmVVB0mnL3e4ySQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
On Fri, Oct 9, 2020 at 10:06 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Fri, Oct 9, 2020 at 8:40 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Thu, Oct 8, 2020 at 2:34 PM Simon Riggs <simon@2ndquadrant.com> wrote:
> > >
> > > On Thu, 8 Oct 2020 at 09:47, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > >
> > > > > This script will wait 10 seconds after INSERT exits
> > > > > before executing TRUNCATE, please wait for it to run.
> > >
> > > Has this been tested with anything other than the one test case?
> > >
> > > It would be good to know how the patch handles a transaction that
> > > contains many aborted subtransactions that contain invals.
> > >
> >
> > Are you thinking from the angle of performance or functionality? I
> > don't see how this patch can impact either of those. Basically, it
> > will not execute any extra invalidations then it is executing without
> > the patch for aborted subtransactions. Can you please explain in a bit
> > more detail about your fear?
> >
> > Having said that, I think it would be a good idea to test the scenario
> > you mentioned to ensure that we have not broken anything unknowingly.
>
> Yeah, even I feel that nothing should impact in this area because on
> abort we are anyway executing all the invalidations and we will
> continue to do so with the patch as well.
>

True, but I think we execute the invalidations only for the streaming
case, otherwise, neither we need to execute invalidations nor we are
doing it for abort case.

>  I will test this scenario
> to ensure nothing is broken.
>

If I have not missed anything then probably you need to prepare a
scenario where we need to do streaming. I am fine with the testing of
the non-streaming case as well if you want to ensure that we have not
broken that case by starting to execute invalidations.


-- 
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Parallel copy