pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Noah Misch <noah@leadboat.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Date: Mon, 19 Jul 2021 14:10:05 -0400
Message-ID: <20210719181005.GB972361@gust.leadboat.com> (raw)
In-Reply-To: <EC1C458C-8A04-4923-87D7-D528F9381707@yandex-team.ru>
References: <20210117072454.GA1709971@rfd.leadboat.com>
	<EF4A43BD-C62C-429B-94EE-9303A1321F47@yandex-team.ru>
	<20210124022743.GA2270535@rfd.leadboat.com>
	<74C78048-70E8-4356-8F10-6370C37136C8@yandex-team.ru>
	<9C782C9D-D53E-4154-B910-46F062A9AE9B@yandex-team.ru>
	<01824242-AA92-4FE9-9BA7-AEBAFFEA3D0C@yandex-team.ru>
	<20210717201240.GA874334@gust.leadboat.com>
	<A74C56AE-FA8A-4BBD-8941-06AA8FED73E1@yandex-team.ru>
	<20210719003009.GA931573@gust.leadboat.com>
	<EC1C458C-8A04-4923-87D7-D528F9381707@yandex-team.ru>

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?





view thread (107+ messages)  latest in thread

Message-ID: <20210719181005.GB972361@gust.leadboat.com>
Permalink:  ../20210719181005.GB972361@gust.leadboat.com/
Also on:    postgresql.org/message-id/20210719181005.GB972361@gust.leadboat.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: noah@leadboat.com, x4mmm@yandex-team.ru, michael@paquier.xyz, tgl@sss.pgh.pa.us, pgsql-bugs@lists.postgresql.org
  Subject: Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
  In-Reply-To: <20210719181005.GB972361@gust.leadboat.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox