Re: SLRUs in the main buffer pool - Page Header definitions - Mailing list pgsql-hackers

From Bagga, Rishu
Subject Re: SLRUs in the main buffer pool - Page Header definitions
Date
Msg-id A45DC000-C7F5-43C1-9E9E-57FB18E2FD0D@amazon.com
Whole thread Raw
In response to Re: SLRUs in the main buffer pool - Page Header definitions  (Ian Lawrence Barwick <barwick@gmail.com>)
Responses Re: SLRUs in the main buffer pool - Page Header definitions
List pgsql-hackers
Hi Heikki and Thomas,


I’ve reworked your patches for moving SLRUs to the buffer cache to add page headers to the SLRUs. Additionally, I’ve
rebasedthis patch on top of the latest commit.
 


Changes in this patch include:

1. page headers on SLRU pages
2. pg_upgrade support to add page headers to existing on-disk SLRU pages
3. a new ReadBuffer mode RBM_TRIM for TrimCLOG and TrimMultiXact
4. Removing concept of External LSNs introduced in Heikki’s patch, as page headers can now store LSNs normally for
SLRUs.¬¬¬¬¬
5. Addressed Serial SLRU asserts in previous patch

We still need to fix asserts triggered from memory allocation in the critical section in Munro’s patch in
RecordNewMultiXact.
 

Currently, in GetNewMultiXact we enter the critical section, and end only after we finish our write, after doing
RecordNewMultiXactin MultiXactIdCreateFromMembers. Now that we’re making ReadBuffer calls in RecordNewMultiXact, we
allocatememory in the critical section, but this isn’t allowed.
 

For now, to avoid triggering asserts, I moved the end of the critical section before doing ReadBuffer calls, but this
couldcause potential data corruption for multixacts in the case ReadBuffer fails. 
 

A potential fix for this issue is to hold on to MultiXactGenLock until we successfully read and write to the buffer, to
ensureno but this would cause ReadBuffer to become a bottleneck as no other backends could access the MultiXact state
data.

We should figure out a way to allow ReadBuffer calls in critical sections specifically for multixacts, as the current
behavioris to panic when multixact data write operations fail. 
 

I would appreciate your thoughts on how we could proceed here.


P.S, Ian, thanks for reminding me to rebase the patch!

Sincerely,

Rishu Bagga, 

Amazon Web Services (AWS)


Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Proposal: Allow user with pg_monitor role to call pg_stat_reset* functions
Next
From: vignesh C
Date:
Subject: Re: Improve tab completion for ALTER FUNCTION/PROCEDURE/ROUTINE