From: | "Bagga, Rishu" <bagrishu(at)amazon(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SLRUs in the main buffer pool, redux |
Date: | 2022-09-17 00:41:14 |
Message-ID: | 1B2B5DB8-7BEE-489E-AEF8-79BE92E07C3F@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Thomas,
While I was working on adding the page headers to SLRU pages on your patch, I came across this code where it seems like "MultiXactIdToMemberPage" is mistakenly being used instead of MultiXactIdToOffsetPage in the TrimMultiXact function.
Below is the area of concern in the patch:
@@ -2045,14 +1977,7 @@ TrimMultiXact(void)
oldestMXactDB = MultiXactState->oldestMultiXactDB;
LWLockRelease(MultiXactGenLock);
- /* Clean up offsets state */
- LWLockAcquire(MultiXactOffsetSLRULock, LW_EXCLUSIVE);
-
- /*
- * (Re-)Initialize our idea of the latest page number for offsets.
- */
- pageno = MultiXactIdToOffsetPage(nextMXact);
- MultiXactOffsetCtl->shared->latest_page_number = pag0eno;
+ pageno = MXOffsetToMemberPage(offset);
Let us know if I am missing something here or if it is an error.
Sincerely,
Rishu Bagga (Amazon Web Services)
On 9/16/22, 5:37 PM, "Thomas Munro" <thomas(dot)munro(at)gmail(dot)com> wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
Rebased, debugged and fleshed out a tiny bit more, but still with
plenty of TODO notes and questions. I will talk about this idea at
PGCon, so I figured it'd help to have a patch that actually applies,
even if it doesn't work quite right yet. It's quite a large patch but
that's partly because it removes a lot of lines...
From | Date | Subject | |
---|---|---|---|
Next Message | bt22nakamorit | 2022-09-17 00:44:33 | Re: Make ON_ERROR_STOP stop on shell script failure |
Previous Message | Peter Geoghegan | 2022-09-17 00:15:24 | Re: Making C function declaration parameter names consistent with corresponding definition names |