On 2022/07/07 16:26, Kyotaro Horiguchi wrote:
+ * ControlFileLock is not required as we are the only
+* updator of these variables.
Isn't it better to add "at this time" or something at the end of the
comment because only we're not always updato
At Thu, 7 Jul 2022 01:11:33 +0900, Fujii Masao
wrote in
>
>
> On 2022/03/16 10:29, Kyotaro Horiguchi wrote:
> > At Wed, 16 Mar 2022 09:19:13 +0900 (JST), Kyotaro Horiguchi
> > wrote in
> >> In short, I split out the two topics other than checkpoint log to
> >> other threads.
> > So, this is a
On 2022/03/16 10:29, Kyotaro Horiguchi wrote:
At Wed, 16 Mar 2022 09:19:13 +0900 (JST), Kyotaro Horiguchi
wrote in
In short, I split out the two topics other than checkpoint log to
other threads.
So, this is about the main topic of this thread, adding LSNs to
checkpint log. Other topics
This patch is currently showing up with a test failure in the CFBot
however I do *not* believe this is a bug in the patch. I think it's a
bug in that test which is being discussed elsewhere.
It's also a very short and straightforward patch that a committer
could probably make a decision about whet
Rupireddy
Date: Fri, 4 Mar 2022 13:22:41 +0900
Subject: [PATCH v13] Add checkpoint and redo LSN to LogCheckpointEnd log
message
It is useful (for debugging purposes) if the checkpoint end message
has the checkpoint LSN(end) and REDO LSN(start). It gives more
context while analyzing checkpoin
Hello, this is a follow-up topic of [1] (add LSNs to checkpint logs).
Many user-facing texts contains wording like "WAL location" or such
like. The attached is WIP patches that fixes such wordings to "WAL
LSN" or alikes.
The attached patches is v13 but it is not changed at all from v12.
My lastes
At Tue, 15 Mar 2022 18:26:26 +0900, Michael Paquier wrote
in
> On Tue, Mar 15, 2022 at 05:23:40PM +0900, Kyotaro Horiguchi wrote:
> > At Tue, 15 Mar 2022 12:19:47 +0530, Bharath Rupireddy
> > wrote in
> >> On Fri, Mar 4, 2022 at 10:40 AM Kyotaro Horiguchi
> >> wrote:
> >> 0001 - I don't thin
On Tue, Mar 15, 2022 at 05:23:40PM +0900, Kyotaro Horiguchi wrote:
> At Tue, 15 Mar 2022 12:19:47 +0530, Bharath Rupireddy
> wrote in
>> On Fri, Mar 4, 2022 at 10:40 AM Kyotaro Horiguchi
>> wrote:
>> 0001 - I don't think you need to do this as UpdateControlFile
>> (update_controlfile) will anyw
Aarchive recovery has ended. Crash recovery ever after should
+ * always recover to the end of WAL
+ */
+ ControlFile->minRecoveryPoint = InvalidXLogRecPtr;
+ ControlFile->minRecoveryPointTLI = 0;
+
+ /* also update local copy */
+ LocalMinRecoveryPoint = InvalidXLogRecPtr;
+ LocalMinRecoveryPo
On Fri, Mar 4, 2022 at 10:40 AM Kyotaro Horiguchi
wrote:
>
> At Mon, 14 Feb 2022 14:52:15 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > In this version , 0001 gets one fix and two comment updates.
>
> While the disucssion on back-patching of 0001 proceeding on another
> branch, the main patch is
>From 1dc663152ba00903f1bd25e7b28540fd97c41bd7 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy
Date: Fri, 4 Mar 2022 13:22:41 +0900
Subject: [PATCH v11 2/5] Add checkpoint and redo LSN to LogCheckpointEnd log
message
It is useful (for debugging purposes) if the checkpoint end message
has the c
At Fri, 25 Feb 2022 16:52:30 +0900 (JST), Kyotaro Horiguchi
wrote in
> Ugh! Wait for a moment. Something's wrong.
Sorry, what is wrong was my working directory. It was broken by my
bogus operation. All the files apply corresponding versions correctly.
regards.
--
Kyotaro Horiguchi
NTT Open
At Fri, 25 Feb 2022 16:47:01 +0900 (JST), Kyotaro Horiguchi
wrote in
> So, this is the patches for pg12-10. 11 can share the same patch with
> 12. 10 has differences in two points.
>
> 10 has ControlFile->prevCheckPoint.
>
> The DETAILS of the "recovery restart point at" message is not
> cap
At Fri, 25 Feb 2022 16:06:31 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 25 Feb 2022 15:31:12 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > While making patches for v12, I see a test failure of pg_rewind for
> > uncertain reason. I'm investigating that but I post this for
> > discussion
At Fri, 25 Feb 2022 15:31:12 +0900 (JST), Kyotaro Horiguchi
wrote in
> While making patches for v12, I see a test failure of pg_rewind for
> uncertain reason. I'm investigating that but I post this for
> discussion.
Hmm. Too stupid. Somehow I overly removed the latchet condition for
minRecover
At Tue, 22 Feb 2022 17:44:01 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Tue, 22 Feb 2022 01:59:45 +0900, Fujii Masao
> wrote in
> >
> > > Of the following, I think we should do (a) and (b) to make future
> > > backpatchings easier.
> > > a) Use RedoRecPtr and PriorRedoPtr after they are as
At Tue, 22 Feb 2022 01:59:45 +0900, Fujii Masao
wrote in
>
> > Of the following, I think we should do (a) and (b) to make future
> > backpatchings easier.
> > a) Use RedoRecPtr and PriorRedoPtr after they are assigned.
> > b) Move assignment to PriorRedoPtr into the ControlFileLock section.
>
On 2022/02/14 14:40, Kyotaro Horiguchi wrote:
For backbranches, the attached for pg14 does part of the full patch.
Thanks for updating the patch!
Of the following, I think we should do (a) and (b) to make future
backpatchings easier.
a) Use RedoRecPtr and PriorRedoPtr after they are assi
ase the started-counter
--
2.27.0
>From 5a78c6a41996d0bc5c2fb21724caf789a0a83d46 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy
Date: Tue, 1 Feb 2022 04:34:54 +
Subject: [PATCH v10 2/5] Add checkpoint and redo LSN to LogCheckpointEnd log
message
It is useful (for debugging purposes) if the
At Mon, 14 Feb 2022 14:40:22 +0900 (JST), Kyotaro Horiguchi
wrote in
> It doesn't apply even on pg13 (due to LSN_FORMAT_ARGS). I will make
> the per-version patches if you are fine with this.
Oops! I forgot to rename the patch to avoid confusion on CF-bots.
I'll resend new version soon to avo
At Fri, 11 Feb 2022 01:00:03 +0900, Fujii Masao
wrote in
>
>
> On 2022/02/09 11:52, Kyotaro Horiguchi wrote:
> > 0001: The fix of CreateRestartPoint
>
> This patch might be ok for the master branch. But since concurrent
> checkpoint and restartpoint can happen in v14 or before, we would need
On 2022/02/09 11:52, Kyotaro Horiguchi wrote:
0001: The fix of CreateRestartPoint
This patch might be ok for the master branch. But since concurrent checkpoint
and restartpoint can happen in v14 or before, we would need another patch based
on that assumption, for the backport. How about fi
c/backend/postmaster/checkpointer.c
index 23f691cd47..8bd4c47b6b 100644
--- a/src/backend/postmaster/checkpointer.c
+++ b/src/backend/postmaster/checkpointer.c
@@ -386,7 +386,6 @@ CheckpointerMain(void)
/* Check if we should perform a checkpoint or a restartpoint. */
do_restartpoint = Recove
On Tue, Feb 8, 2022 at 2:10 PM Kyotaro Horiguchi
wrote:
> > Thus.. the attached removes the ambiguity of of the proposed patch
> > about the LSNs in the restartpoint-ending log message.
>
> Thoughts?
Thanks for the patch. I have few comments on the
v1-0001-Get-rid-of-unused-path-to-handle-concurr
Mmm.. checkpoint and checkpointer are quite confusing in this context..
At Tue, 08 Feb 2022 16:58:22 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Mon, 7 Feb 2022 13:51:31 +0900, Fujii Masao
> wrote in
> >
> >
> > On 2022/02/07 12:02, Kyotaro Horiguchi wrote:
> > > - If any later checkpoint
At Mon, 7 Feb 2022 13:51:31 +0900, Fujii Masao
wrote in
>
>
> On 2022/02/07 12:02, Kyotaro Horiguchi wrote:
> > - If any later checkpoint/restartpoint has been established, just skip
> >remaining task then return false. (!chkpt_was_latest)
> >(I'm not sure this can happen, though.)
> >
On 2022/02/07 12:02, Kyotaro Horiguchi wrote:
- If any later checkpoint/restartpoint has been established, just skip
remaining task then return false. (!chkpt_was_latest)
(I'm not sure this can happen, though.)
- we update control file only when archive recovery is still ongoing.
This
At Mon, 07 Feb 2022 10:16:34 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 4 Feb 2022 10:59:04 +0900, Fujii Masao
> wrote in
> > On 2022/02/03 15:50, Kyotaro Horiguchi wrote:
> > > By the way, restart point should start only while recoverying, and at
> > > the timeof the start both checkp
At Fri, 4 Feb 2022 10:59:04 +0900, Fujii Masao
wrote in
>
>
> On 2022/02/03 15:50, Kyotaro Horiguchi wrote:
> > On way to take. In that case should we log something like
> > "Restartpoint canceled" or something?
>
> +1
>
>
> > By the way, restart point should start only while recoverying, a
On 2022/02/03 15:50, Kyotaro Horiguchi wrote:
On way to take. In that case should we log something like
"Restartpoint canceled" or something?
+1
By the way, restart point should start only while recoverying, and at
the timeof the start both checkpoint.redo and checkpoint LSN are
already p
At Thu, 3 Feb 2022 13:59:03 +0900, Fujii Masao
wrote in
>
>
> On 2022/02/02 23:46, Bharath Rupireddy wrote:
> > On Tue, Feb 1, 2022 at 9:39 PM Fujii Masao
> > wrote:
> >> I found that CreateRestartPoint() already reported the redo lsn as
> >> follows after emitting the restartpoint log messag
On 2022/02/02 23:46, Bharath Rupireddy wrote:
On Tue, Feb 1, 2022 at 9:39 PM Fujii Masao wrote:
I found that CreateRestartPoint() already reported the redo lsn as follows
after emitting the restartpoint log message. To avoid duplicated logging of the
same information, we should update this
On Tue, Feb 1, 2022 at 9:39 PM Fujii Masao wrote:
> I found that CreateRestartPoint() already reported the redo lsn as follows
> after emitting the restartpoint log message. To avoid duplicated logging of
> the same information, we should update this code?
>
> ereport((log_checkpoints ?
Greetings,
* Fujii Masao (masao.fu...@oss.nttdata.com) wrote:
> On 2022/02/01 22:03, Bharath Rupireddy wrote:
> >On Tue, Feb 1, 2022 at 11:58 AM Kyotaro Horiguchi
> > wrote:
> >>>Modified in v8.
> >>
> >>0001 looks good to me.
>
> I found that CreateRestartPoint() already reported the redo lsn as
On 2022/02/01 22:03, Bharath Rupireddy wrote:
On Tue, Feb 1, 2022 at 11:58 AM Kyotaro Horiguchi
wrote:
Modified in v8.
0001 looks good to me.
I found that CreateRestartPoint() already reported the redo lsn as follows
after emitting the restartpoint log message. To avoid duplicated loggi
On Tue, Feb 1, 2022 at 11:58 AM Kyotaro Horiguchi
wrote:
> > Modified in v8.
>
> 0001 looks good to me.
>
> I tend to agree to 0002.
Thanks.
> FWIW, I collected other user-facing usage of "location" as LSN.
>
> xlog.c:11298, 11300: (in backup-label)
> appendStringInfo(labelfile, "START WAL LO
At Tue, 1 Feb 2022 10:08:04 +0530, Bharath Rupireddy
wrote in
> On Tue, Feb 1, 2022 at 9:49 AM Fujii Masao
> wrote:
> >
> > My previous comment was confusing... Probably I understand why you tried to
> > put this information in checkpoint log message. But I was suggesting to put
> > that inf
On Tue, Feb 1, 2022 at 9:49 AM Fujii Masao wrote:
>
> My previous comment was confusing... Probably I understand why you tried to
> put this information in checkpoint log message. But I was suggesting to put
> that information at the end of log message instead of the beginning of it.
> Because
On 2022/02/01 13:01, Bharath Rupireddy wrote:
On Tue, Feb 1, 2022 at 9:10 AM Fujii Masao wrote:
The order of arguments for LSN seems wrong.
LSN_FORMAT_ARGS(ControlFile->checkPoint) should be specified ahead of
LSN_FORMAT_ARGS(ControlFile->checkPointCopy.redo)?
Thanks. Corrected.
Thanks
On Tue, Feb 1, 2022 at 9:10 AM Fujii Masao wrote:
> The order of arguments for LSN seems wrong.
> LSN_FORMAT_ARGS(ControlFile->checkPoint) should be specified ahead of
> LSN_FORMAT_ARGS(ControlFile->checkPointCopy.redo)?
Thanks. Corrected.
> Could you tell me why the information for LSN is rep
On 2022/02/01 10:44, Nathan Bossart wrote:
On Tue, Feb 01, 2022 at 12:23:10AM +0530, Bharath Rupireddy wrote:
On Tue, Feb 1, 2022 at 12:00 AM Nathan Bossart wrote:
I think the pg_controldata change needs some extra spaces for alignment,
but otherwise these patches seem reasonable to me.
T
On Tue, Feb 01, 2022 at 12:23:10AM +0530, Bharath Rupireddy wrote:
> On Tue, Feb 1, 2022 at 12:00 AM Nathan Bossart
> wrote:
>> I think the pg_controldata change needs some extra spaces for alignment,
>> but otherwise these patches seem reasonable to me.
>
> Thanks. My bad it was. Changed in v6.
On Tue, Feb 1, 2022 at 12:00 AM Nathan Bossart wrote:
>
> On Mon, Jan 31, 2022 at 11:45:19PM +0530, Bharath Rupireddy wrote:
> > Thanks. Here are 2 patches, 0001 for adding checkpoint lsn and redo
> > lsn in the checkpoint completed message and 0002 for changing the
> > "location" to LSN in pg_con
On Mon, Jan 31, 2022 at 11:45:19PM +0530, Bharath Rupireddy wrote:
> Thanks. Here are 2 patches, 0001 for adding checkpoint lsn and redo
> lsn in the checkpoint completed message and 0002 for changing the
> "location" to LSN in pg_controdata's output. With the 0002,
> pg_control_checkpont, pg_contr
g_controdata's output. With the 0002,
pg_control_checkpont, pg_controldata and checkpoint completed message
will all be in sync with the checkpoint lsn and redo lsn.
Regards,
Bharath Rupireddy.
From beafea457cd80266c6e517862ed819da7b3c8ec0 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy
Date: Mo
Greetings,
* Bharath Rupireddy (bharath.rupireddyforpostg...@gmail.com) wrote:
> On Fri, Jan 28, 2022 at 11:16 AM Nathan Bossart
> wrote:
> > I know I voted for "start=%X/%X, end=%X/%X," but looking at this again, I
> > wonder if it could be misleading. "start" is the redo location, and "end"
>
On Fri, Jan 28, 2022 at 11:16 AM Nathan Bossart
wrote:
>
> I know I voted for "start=%X/%X, end=%X/%X," but looking at this again, I
> wonder if it could be misleading. "start" is the redo location, and "end"
> is the location of the checkpoint record, but I could understand why
> someone might t
On Fri, Jan 28, 2022 at 08:43:36AM +0530, Bharath Rupireddy wrote:
> 2022-01-28 03:06:10.213 UTC [2409486] LOG: checkpoint starting:
> immediate force wait
> 2022-01-28 03:06:10.257 UTC [2409486] LOG: checkpoint complete:
> start=0/14D9510, end=0/14D9548; wrote 4 buffers (0.0%); 0 WAL file(s)
> a
On Thu, Jan 20, 2022 at 8:30 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 20 Jan 2022 00:36:32 +, "Bossart, Nathan"
> wrote in
> > On 1/3/22, 5:52 PM, "Kyotaro Horiguchi" wrote:
> > > It seems to me "LSN" or just "location" is more confusing or
> > > mysterious than "REDO LSN" for the average us
On Thu, Jan 27, 2022 at 08:37:37PM +0530, Bharath Rupireddy wrote:
> I'm still not clear how the REDO location can be treated as a start
> LSN? Can someone throw some light one what this checkpoint's REDO
> location is?
It's the WAL insert location at the time the checkpoint began (i.e., where
you
On Thu, Jan 20, 2022 at 6:06 AM Bossart, Nathan wrote:
>
> On 1/3/22, 5:52 PM, "Kyotaro Horiguchi" wrote:
> > It seems to me "LSN" or just "location" is more confusing or
> > mysterious than "REDO LSN" for the average user. If we want to avoid
> > being technically too detailed, we would use just
At Thu, 20 Jan 2022 00:36:32 +, "Bossart, Nathan"
wrote in
> On 1/3/22, 5:52 PM, "Kyotaro Horiguchi" wrote:
> > It seems to me "LSN" or just "location" is more confusing or
> > mysterious than "REDO LSN" for the average user. If we want to avoid
> > being technically too detailed, we would
On 1/3/22, 5:52 PM, "Kyotaro Horiguchi" wrote:
> It seems to me "LSN" or just "location" is more confusing or
> mysterious than "REDO LSN" for the average user. If we want to avoid
> being technically too detailed, we would use just "start LSN=%X/%X,
> end LSN=%X/%X". And it is equivalent to "WAL
e I don't want to break that. Here's the v3 patch
that I think will work better. Please review.
Regards,
Bharath Rupireddy.
From b6f2a53bcaea2d37e317bc3d9922893c10712d3a Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy
Date: Fri, 14 Jan 2022 12:55:30 +0000
Subject: [PATCH v3] Add che
-LogCheckpointEnd-l.patch
Description: Binary data
From 999cfd53ce4e16ccfff94c0022cd80fe8ff84be5 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy
Date: Tue, 28 Dec 2021 02:45:51 +
Subject: [PATCH v2] Add checkpoint and redo LSN to LogCheckpointEnd log
message
It is useful (for debugging purposes) if
On Wed, Jan 12, 2022 at 2:52 PM Thomas Munro wrote:
>
> By way of documentation, I've just now tried to answer these question
> in the new FAQ at:
>
> https://wiki.postgresql.org/wiki/Cfbot
Great! Thanks a lot!
Thomas Munro writes:
> By way of documentation, I've just now tried to answer these question
> in the new FAQ at:
> https://wiki.postgresql.org/wiki/Cfbot
Thanks!
regards, tom lane
On Wed, Jan 12, 2022 at 7:37 PM Tom Lane wrote:
> Julien Rouhaud writes:
> > On Wed, Jan 12, 2022 at 01:19:22AM -0500, Tom Lane wrote:
> >> 2. You are attaching some random files, and would like to not
> >> displace the cfbot's idea of the latest patchset.
>
> > I'm assuming that someone wanting
On Wed, Jan 12, 2022 at 2:37 PM Tom Lane wrote:
>
> AFAIK, if you're submitting a patch then you have to attach a complete
> patchset, or the cfbot will be totally lost. Getting the bot to
> understand incremental patches would be useful for sure ... but it's
> outside the scope of what I'm askin
Julien Rouhaud writes:
> On Wed, Jan 12, 2022 at 01:19:22AM -0500, Tom Lane wrote:
>> 2. You are attaching some random files, and would like to not
>> displace the cfbot's idea of the latest patchset.
> I'm assuming that someone wanting to send an additional patch to be applied on
> top of the OP
On Wed, Jan 12, 2022 at 01:19:22AM -0500, Tom Lane wrote:
> Julien Rouhaud writes:
> > For this kind of situation I think that the usual solution is to use a
> > .txt extension to make sure that the cfbot won't try to apply it.
>
> Yeah ... this has come up before. Is there a documented way to
>
Julien Rouhaud writes:
> For this kind of situation I think that the usual solution is to use a
> .txt extension to make sure that the cfbot won't try to apply it.
Yeah ... this has come up before. Is there a documented way to
attach files that the cfbot will ignore?
Two specific scenarios seem
Hi,
On Tue, Dec 28, 2021 at 10:56 AM Bharath Rupireddy
wrote:
>
> attaching v1-0001-XXX from the initial mail again just for the sake of
> completion:
Unfortunately this breaks the cfbot as it tries to apply this patch
too: http://cfbot.cputube.org/patch_36_3474.log.
For this kind of situation
At Tue, 28 Dec 2021 08:26:28 +0530, Bharath Rupireddy
wrote in
> On Fri, Dec 24, 2021 at 5:54 PM Bharath Rupireddy
> wrote:
> >
> > On Fri, Dec 24, 2021 at 5:42 PM Michael Paquier wrote:
> > >
> > > On Fri, Dec 24, 2021 at 02:51:34PM +0900, Kyotaro Horiguchi wrote:
> > > > I thougt about somet
On Fri, Dec 24, 2021 at 5:54 PM Bharath Rupireddy
wrote:
>
> On Fri, Dec 24, 2021 at 5:42 PM Michael Paquier wrote:
> >
> > On Fri, Dec 24, 2021 at 02:51:34PM +0900, Kyotaro Horiguchi wrote:
> > > I thougt about something like the following, but your proposal may be
> > > clearer.
> >
> > +"L
On Fri, Dec 24, 2021 at 5:42 PM Michael Paquier wrote:
>
> On Fri, Dec 24, 2021 at 02:51:34PM +0900, Kyotaro Horiguchi wrote:
> > I thougt about something like the following, but your proposal may be
> > clearer.
>
> +"LSN=%X/%X, REDO LSN=%X/%X",
> This could be rather confusing for the averag
On Fri, Dec 24, 2021 at 02:51:34PM +0900, Kyotaro Horiguchi wrote:
> I thougt about something like the following, but your proposal may be
> clearer.
+"LSN=%X/%X, REDO LSN=%X/%X",
This could be rather confusing for the average user, even if I agree
that this is some information that only an ad
On Fri, Dec 24, 2021 at 11:21 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 23 Dec 2021 20:35:54 +0530, Bharath Rupireddy
> wrote in
> > Hi,
> >
> > It is useful (for debugging purposes) if the checkpoint end message
> > has the checkpoint LSN and REDO LSN [1]. It gives more context while
> > analyzin
At Thu, 23 Dec 2021 20:35:54 +0530, Bharath Rupireddy
wrote in
> Hi,
>
> It is useful (for debugging purposes) if the checkpoint end message
> has the checkpoint LSN and REDO LSN [1]. It gives more context while
> analyzing checkpoint-related issues. The pg_controldata gives the last
> checkpoi
Hi,
It is useful (for debugging purposes) if the checkpoint end message
has the checkpoint LSN and REDO LSN [1]. It gives more context while
analyzing checkpoint-related issues. The pg_controldata gives the last
checkpoint LSN and REDO LSN, but having this info alongside the log
message helps anal
70 matches
Mail list logo
