Re: Parallel scan with SubTransGetTopmostTransaction assert coredump

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

In response to

Responses

Browse pgsql-hackers by date

  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