From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Track Oldest Initialized WAL Buffer Page |
Date: | 2023-03-01 07:03:36 |
Message-ID: | CALj2ACX-UT6o8=ZdKHgd1fzRuatcTeqrC7wQ79eqms613VifJQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 1, 2023 at 9:49 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> On Tue, Feb 28, 2023 at 11:12:29AM +0530, Bharath Rupireddy wrote:
> > On Tue, Feb 28, 2023 at 5:52 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> >> It's confusing to me that OldestInitializedPage is set to NewPageBeginPtr.
> >> Doesn't that set it to the beginning of the newest initialized page?
> >
> > Yes, that's the intention, see below. OldestInitializedPage points to
> > the start address of the oldest initialized page whereas the
> > InitializedUpTo points to the end address of the latest initialized
> > page. With this, one can easily track all the WAL between
> > OldestInitializedPage and InitializedUpTo.
>
> This is where I'm confused. Why would we set the variable for the start
> address of the _oldest_ initialized page to the start address of the
> _newest_ initialized page? I must be missing something obvious, so sorry
> if this is a silly question.
That's the crux of the patch. Let me clarify it a bit.
Firstly, we try to set OldestInitializedPage at the end of the
recovery but that's conditional, that is, only when the last replayed
WAL record spans partially to the end block.
Secondly, we set OldestInitializedPage while initializing the page for
the first time, so the missed-conditional case above gets coverd too.
And, OldestInitializedPage isn't updated for every new initialized
page, only when the previous OldestInitializedPage is being reused
i.e. the wal_buffers are full and it wraps around. Please see the
comment and the condition
XLogRecPtrToBufIdx(XLogCtl->OldestInitializedPage) == nextidx which
holds true if we're crossing-over/wrapping around previous
OldestInitializedPage.
+ /*
+ * Try updating oldest initialized XLog buffer page.
+ *
+ * Update it if we are initializing an XLog buffer page for the first
+ * time or if XLog buffers are full and we are wrapping around.
+ */
+ if (XLogRecPtrIsInvalid(XLogCtl->OldestInitializedPage) ||
+ XLogRecPtrToBufIdx(XLogCtl->OldestInitializedPage) == nextidx)
+ {
+ Assert(XLogCtl->OldestInitializedPage < NewPageBeginPtr);
+
+ XLogCtl->OldestInitializedPage = NewPageBeginPtr;
+ }
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2023-03-01 07:17:20 | Re: meson: Add equivalent of configure --disable-rpath option |
Previous Message | Julien Rouhaud | 2023-03-01 06:55:27 | Re: pg_upgrade and logical replication |