Date: Mon, 30 Mar 2020 17:27:58 +0200
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>,
	Michael Paquier <michael@paquier.xyz>,
	Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: PATCH: logical_work_mem and logical streaming of large
 in-progress transactions
Message-ID: <20200330152758.fgp62lwb2ug7cl2a@development>
References: 
 <CAFiTN-uNzEyY3YL1EZabWcG=Bah1nO8hno+-UaAkCDcfCGYC0g@mail.gmail.com>
 <20200303214646.6adway2z5wnapjem@development>
 <CAFiTN-sn0Bd4Q72Cn9t8-mZp1sxWRv2SmUoeR_7J05SqNTR--g@mail.gmail.com>
 <CAA4eK1KyrP6m53FQV5v0gysEnaTHPdc2xYT0KeNN+fhOcedRwA@mail.gmail.com>
 <CAFiTN-uBd3p50s=kfEiSbg93_Fnf_VU+haS4FqBZAm7PmbX69g@mail.gmail.com>
 <CAA4eK1LkLU5frY4kZGO38d8m6R504H+GbfkwsQLAp7sQ-4oqbw@mail.gmail.com>
 <20200329005905.ooxq25qyjwn2mvxz@development>
 <CAA4eK1LvUDNaCJUZEh5BhV31U6OnNWP=OCUmyZM2k4JGx5CXvQ@mail.gmail.com>
 <20200329153105.mdryxzz562tg65pk@development>
 <CAA4eK1JHxMaeQhvfpaBpUCLoeg3=RbbQQ_h0O0WwOU2kssRFsg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="vy6eyainsxhnm65b"
Content-Disposition: inline
In-Reply-To: 
 <CAA4eK1JHxMaeQhvfpaBpUCLoeg3=RbbQQ_h0O0WwOU2kssRFsg@mail.gmail.com>
Precedence: bulk


--vy6eyainsxhnm65b
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline

On Mon, Mar 30, 2020 at 11:47:57AM +0530, Amit Kapila wrote:
>On Sun, Mar 29, 2020 at 9:01 PM Tomas Vondra
><tomas.vondra@2ndquadrant.com> wrote:
>>
>> On Sun, Mar 29, 2020 at 11:19:21AM +0530, Amit Kapila wrote:
>> >On Sun, Mar 29, 2020 at 6:29 AM Tomas Vondra
>> ><tomas.vondra@2ndquadrant.com> wrote:
>> >>
>> >> Ummm, how is that different from what the patch is doing now? I mean, we
>> >> only write the top-level XID for the first WAL record in each subxact,
>> >> right? Or what would be the difference with your approach?
>> >>
>> >
>> >We have to do what the patch is currently doing and additionally, we
>> >will set this flag after PGPROC_MAX_CACHED_SUBXIDS which would allow
>> >us to call ProcArrayApplyXidAssignment during WAL replay only after
>> >PGPROC_MAX_CACHED_SUBXIDS number of subxacts.  It will help us in
>> >clearing the KnownAssignedXids at the same time as we do now, so no
>> >additional performance overhead.
>> >
>>
>> Hmmm. So we'd still log assignment twice? Or would we keep just the
>> immediate assignments (embedded into xlog records), and cache the
>> subxids on the replica somehow?
>>
>
>I think we need to cache the subxids on the replica somehow but I
>don't have a very good idea for it.  Basically, there are two ways to
>do it (a) Change the KnownAssignedXids in some way so that we can
>easily find this information without losing on the current benefits of
>it.  I can't think of a good way to do that and even if we come up
>with something, it could easily be a lot of work, (b) Cache the
>subxids for a particular transaction in local memory along with
>KnownAssignedXids.  This is doable but now we have two data-structures
>(one in shared memory and other in local memory) managing the same
>information in different ways.
>
>Do you have any other ideas?

I don't follow. Why couldn't we have a simple cache on the standby? It
could be either a simple array or a hash table (with the top-level xid
as hash key)?

I think the single array would be sufficient, but the hash table would
allow keeping the apply logic more or less as it's today. See the
attached patch that adds such cache - I do admit I haven't tested this,
but hopefully it's a sufficient illustration of the idea.

It does not handle cleanup of the cache, but I think that should not be
difficult - we simply need to remove entries for transactions that got
committed or rolled back. And do something about transactions without an
explicit commit/rollback record, but that can be done by also handling
XLOG_RUNNING_XACTS (by removing anything preceding oldestRunningXid).

I don't think this is particularly complicated or a lot of code, and I
don't see why would it require data structures in shared memory. Only
the walreceiver on standby needs to worry about this, no?

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--vy6eyainsxhnm65b
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="xid-assignment-v13-fix.patch"

diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 1951103b26..b85c046b41 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7300,6 +7300,19 @@ StartupXLOG(void)
 					TransactionIdIsValid(record->xl_xid))
 					RecordKnownAssignedTransactionIds(record->xl_xid);
 
+				/*
+				* Assign subtransaction xids to the top level xid if the
+				* record has that information. This is required at most
+				* once per subtransactions.
+				*/
+				if (TransactionIdIsValid(xlogreader->toplevel_xid) &&
+					standbyState >= STANDBY_INITIALIZED)
+				{
+					Assert(XLogStandbyInfoActive());
+					ProcArrayCacheXidAssignment(xlogreader->toplevel_xid,
+												record->xl_xid);
+				}
+
 				/* Now apply the WAL record itself */
 				RmgrTable[record->xl_rmid].rm_redo(xlogreader);
 
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index cfb88db4a4..efddd0e1e6 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -958,6 +958,53 @@ ProcArrayApplyXidAssignment(TransactionId topxid,
 	LWLockRelease(ProcArrayLock);
 }
 
+static HTAB *xidAssignmentsHash = NULL;
+
+typedef struct XidAssignmentEntry
+{
+	/* the hash lookup key MUST BE FIRST */
+	TransactionId	topXid;
+
+	int				nsubxids;
+	TransactionId	subxids[PGPROC_MAX_CACHED_SUBXIDS];
+} XidAssignmentEntry;
+
+void
+ProcArrayCacheXidAssignment(TransactionId topXid, TransactionId subXid)
+{
+	XidAssignmentEntry *entry;
+	bool				found;
+
+	if (xidAssignmentsHash == NULL)
+	{
+		/* First time through: initialize the hash table */
+		HASHCTL		ctl;
+
+		MemSet(&ctl, 0, sizeof(ctl));
+		ctl.keysize = sizeof(TransactionId);
+		ctl.entrysize = sizeof(XidAssignmentEntry);
+		xidAssignmentsHash = hash_create("XID assignment cache", 256,
+										 &ctl, HASH_ELEM | HASH_BLOBS);
+	}
+
+	/* Look for an existing entry */
+	entry = (XidAssignmentEntry *) hash_search(xidAssignmentsHash,
+											 (void *) &topXid,
+											 HASH_ENTER, &found);
+
+	if (!found)
+		entry->nsubxids = 0;
+
+	entry->subxids[entry->nsubxids++] = subXid;
+
+	/* after reaching the limit, apply the assignments for this top XID */
+	if (entry->nsubxids == PGPROC_MAX_CACHED_SUBXIDS)
+	{
+		ProcArrayApplyXidAssignment(topXid, entry->nsubxids, entry->subxids);
+		entry->nsubxids = 0;
+	}
+}
+
 /*
  * TransactionIdIsInProgress -- is given transaction running in some backend
  *
diff --git a/src/include/storage/procarray.h b/src/include/storage/procarray.h
index a5c7d0c064..17d89bdd7e 100644
--- a/src/include/storage/procarray.h
+++ b/src/include/storage/procarray.h
@@ -67,6 +67,7 @@ extern void ProcArrayInitRecovery(TransactionId initializedUptoXID);
 extern void ProcArrayApplyRecoveryInfo(RunningTransactions running);
 extern void ProcArrayApplyXidAssignment(TransactionId topxid,
 										int nsubxids, TransactionId *subxids);
+extern void ProcArrayCacheXidAssignment(TransactionId topxid, TransactionId subxid);
 
 extern void RecordKnownAssignedTransactionIds(TransactionId xid);
 extern void ExpireTreeKnownAssignedTransactionIds(TransactionId xid,

--vy6eyainsxhnm65b--