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
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 have moved to other treads [1], [2] ,
[3].
I th
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
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 anyway update it, no?
> + /* Update control file using current time */
> + Cont
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
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 iself gets looks like as if rotten on
CF-App. So I rebased v10 on the cu
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
At Mon, 14 Feb 2022 14:42:18 +0900 (JST), Kyotaro Horiguchi
wrote in
> I'll resend new version soon to avoid the confusion..
In this version , 0001 gets one fix and two comment updates.
-* Archive recovery have ended. Crash recovery ever after
should always
+*
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
Hi, Bharath.
At Tue, 8 Feb 2022 14:33:01 +0530, Bharath Rupireddy
wrote in
> 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?
>
> Th
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
On Mon, Jan 31, 2022 at 8:41 PM Stephen Frost wrote:
>
> > Thanks for your review. In summary, we have these options to choose
> > checkpoint LSN and last REDO LSN:
> >
> > 1) "start=%X/%X, end=%X/%X" (ControlFile->checkPointCopy.redo,
> > ControlFile->checkPoint)
> > 2) "lsn=%X/%X, redo lsn=%X/
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
On Thu, Jan 13, 2022 at 11:50 AM Bharath Rupireddy
wrote:
> Thanks. IMO, the following format of logging is better, so attaching
> the v2-0001-Add-checkpoint-and-redo-LSN-to-LogCheckpointEnd-l.patch as
> .patch
>
> 2021-12-28 02:52:24.464 UTC [2394396] LOG: checkpoint completed at
> location=0/2
On Wed, Jan 12, 2022 at 11:39 AM Julien Rouhaud wrote:
>
> 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
> t
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
69 matches
Mail list logo
