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

On Mon, Mar 29, 2021 at 11:50 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> 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.

Not unless the command counter had been advanced, which shouldn't be
happening anyway.

I think it's probably fundamentally impossible to allow the command
counter to advance during a parallel operation. The whole point of the
command counter mechanism is that you finish one body of work, then
bump the command counter so that all the changes become visible before
you start doing the next set of things. That doesn't really make sense
in a parallel context, and not just because of any difficulty of
synchronizing the value. It's actually trying to make sure that we
finish X first and only then do Y, which is opposed to what
parallelism is all about.

But I don't think there's anything more than incidental preventing us
from assigning an XID in a parallel operation. Contrary to what you
allege here, assigning an XID doesn't change the set of tuples we can
see - nor do any inserts, updates, or deletes it performs afterward,
until such time as the command counter is bumped. We would need to
make sure that two different participants in the parallel operation
don't both get an XID, because we don't want the transaction to end up
with two different XIDs. We want the second one to instead discover
the XID that the other one got. But that's not a definitional
question, like with the command counter. It's "just" a programming
problem.

--
Robert Haas
EDB: http://www.enterprisedb.com