Date: Tue, 20 Jul 2021 17:49:36 -0400
From: Noah Misch <noah@leadboat.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>,
	pgsql-bugs@lists.postgresql.org
Subject: Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Message-ID: <20210720214936.GA1040253@gust.leadboat.com>
References: <20210719181005.GB972361@gust.leadboat.com>
 <1727EC55-0709-4E06-91C9-212682A134C7@yandex-team.ru>
 <BFC46D37-D67B-42DA-8B2C-6CA761911DF7@yandex-team.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BFC46D37-D67B-42DA-8B2C-6CA761911DF7@yandex-team.ru>
Archived-At: 
 <https://www.postgresql.org/message-id/20210720214936.GA1040253%40gust.leadboat.com>
Precedence: bulk

On Wed, Jul 21, 2021 at 12:38:25AM +0500, Andrey Borodin wrote:
> > 19 июля 2021 г., в 23:41, Andrey Borodin <x4mmm@yandex-team.ru> написал(а):
> > > 19 июля 2021 г., в 23:10, Noah Misch <noah@leadboat.com> написал(а):
> > > ﻿On Mon, Jul 19, 2021 at 12:10:52PM +0500, Andrey Borodin wrote:
> > >>>> 19 июля 2021 г., в 05:30, Noah Misch <noah@leadboat.com> написал(а):
> > >>> 
> > >>> To fix $SUBJECT, it sounds like we need a way to identify a transaction,
> > >>> usable as early as the transaction's first catalog access and remaining valid
> > >>> until COMMIT PREPARED finishes.  We may initially see a transaction as having
> > >>> a VXID and no XID, then later need to wait for that transaction when it has
> > >>> entered prepared state, having an XID and no VXID.  How might we achieve that?
> > >> 
> > >> PFA draft with vxid->xid mapping and subsequent wait for it. The patch, obviously, lacks a ton of comments explaining what is going on.
> > >> We write actual VXID into dummy proc entries of prepared xact.
> > >> When we wait for vxid we try to convert it to xid through real proc entry. If we cannot do so - we lookup in shared 2pc state. If vxid is not there - it means it is already gone and there's nothing to wait.
> > > 
> > > When the system reuses BackendId values, it reuses VXID values.  In the
> > > general case, two prepared transactions could exist simultaneously with the
> > > same BackendId+LocalTransactionId.  Hmm.  It could be okay to have a small
> > > probability that CIC waits on more transactions than necessary.  Suppose we
> > > have three PGPROC entries with the same VXID, two prepared transactions and
> > > one regular transaction.  Waiting for all three could be tolerable, though
> > > avoiding that would be nice.  Should we follow transactions differently to
> > > avoid that?
> > 
> > We don’t have to wait for regular Xid in this case at all. Because it would be finished with VXID.

I don't understand those two sentences.  Could you write more?

> > We are looking for transaction that was only VXID during GetLockConflicts(). In conflicts array we may have each VXID only once.
> > Other 2PCs with same VXID may be older or newer than target 2PC.
> > Older 2PCs must be with XID in conflicts array. So we might wait for all 2PC with known XIDs. Then for each ambiguous VXID->XID mapping choose oldest XID.

> Unfortunately, this is just wrong. Older 2PC with same VXID don't have to be in conflicts array. They might be of some other unrelated 2PC working with different relations.

I agree.  Would it work to do the following sequence in WaitForLockers()?

1. In GetLockConflicts(), record a list of conflicting XIDs.  Also record a
   list of conflicting LXIDs having no XID.
2. Wait on all LXIDs recorded in (1).  They have either ended or converted to
   prepared transactions.
3. Inner-join the present list of prepared transactions with the list of
   LXIDs from (1).  Record the XIDs of matched entries.
4. Wait on all XIDs recorded in (1) and (3).

While that may wait on some prepared XIDs needlessly, it can't degrade into
persistent starvation.  We could reduce the chance of a needless XID wait by
remembering the list of old prepared XIDs before (1) and not adding any of
those remembered, old XIDs in (3).  That last bit probably would be
unjustified complexity, but maybe not.