Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode

On Tue, Mar 30, 2021 at 12:43 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Mon, Mar 29, 2021 at 6:01 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > A naive question about this scheme: What if the worker that acquires
> > the XID writes some row and another worker reads that row before it
> > gets to see the XID information? I think it won't treat such a row is
> > written by its own transaction. Won't such a scheme lead to different
> > behavior than serial inserts or where we have acquired XID before
> > starting parallel-operation?
>
> Well, this is the sort of thing that somebody would need to analyze as
> part of implementing something like this, but off hand I don't quite
> see what the problem is.
>

Say, the worker (w-1) that acquires the XID (501) deletes the tuple
(CTID: 0, 2). Now, another worker (w-2) reads that tuple (CTID: 0, 2),
I think it would consider that the tuple is still visible to its
snapshot but if the w-2 knows that 501 is its own XID, it would have
been considered it as (not-visible) deleted. Now, if I am not missing
anything here, I think this can happen when multiple updates to the
same row happen and new rows get added to the new page.

Even, if there are no hazards with the new XID machinery, I am not
sure if we want to consider this as a pre-requisite to enable Inserts
for parallel-select work. We might want to focus on partitioning and
other caching-related stuff to rework this implementation. We might
want to consider this new XID sharing machinery for actual parallel
Inserts/Updates/Deletes if we think it is important to enabling those
parallel operations.

--
With Regards,
Amit Kapila.