From: | Maxim Orlov <m(dot)orlov(at)postgrespro(dot)ru> |
---|---|
To: | Greg Nancarrow <gregn4422(at)gmail(dot)com> |
Cc: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Pengchengliu <pengchengliu(at)tju(dot)edu(dot)cn>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel scan with SubTransGetTopmostTransaction assert coredump |
Date: | 2021-06-04 12:30:15 |
Message-ID: | 09788181118f7bd8000d3bb097e0720f@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Just a note here. After examining the core dump I did notice something.
While in XidInMVCCSnapshot call the snapshot->suboverflowed is set true
although subxip == NULL and subxcnt == 0. As far as I understand,
snapshot->suboverflowed is set true in the GetRunningTransactionData
call.
And then I decided to put elog around CurrentRunningXacts->subxcnt's
assigment.
diff --git a/src/backend/storage/ipc/procarray.c
b/src/backend/storage/ipc/procarray.c
index 42a89fc5dc9..3d2db02f580 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -2781,6 +2781,9 @@ GetRunningTransactionData(void)
* increases if slots do.
*/
+ if (suboverflowed)
+ elog(WARNING, " >>> CurrentRunningXacts->subxid_overflow
is true");
+
CurrentRunningXacts->xcnt = count - subcount;
CurrentRunningXacts->subxcnt = subcount;
CurrentRunningXacts->subxid_overflow = suboverflowed;
... and did get a bunch of messages. I.e. subxid_overflow is set true
very often.
I've increased the value of PGPROC_MAX_CACHED_SUBXIDS. Once it becomes
more than 120 there are no messages and no failed assertions are
provided any more.
---
Best regards,
Maxim Orlov.
Attachment | Content-Type | Size |
---|---|---|
max-cached-subxibds.patch | text/x-diff | 1015 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2021-06-04 12:34:42 | Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM |
Previous Message | Tomas Vondra | 2021-06-04 11:52:28 | Re: postgres_fdw batching vs. (re)creating the tuple slots |