On Tue, Oct 13, 2020 at 7:57 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Amit Kapila <amit.kapila16@gmail.com> writes:
> > I am able to reproduce this problem via debugger. Basically, execute
> > the Insert mentioned above from one the psql sessions and in
> > ExecInsert() stop the execution once 'estate->es_processed > 4000' and
> > then from another psql terminal execute some DDL which will be ignored
> > but will any try to decode commit. Then perform 'continue' in the
> > first session. This will lead to inconsistent stats value depending
> > upon at what time DDL is performed. I'll push the patch as I am more
> > confident now.
>
> So ... doesn't this mean that if the concurrent transaction commits very
> shortly after our query starts, decoding might stop without having ever
> spilled at all?
>
I am assuming in "our query starts" you refer to Insert statement used
in the test. No, the decoding (and required spilling) will still
happen. It is only that we will try to send the stats accumulated by
that time which will be zero. And later when the decoding of our
Insert transaction is finished it will again send the updated stats.
It should work fine in this or similar scenarios.
--
With Regards,
Amit Kapila.
