On 2021/10/05 10:58, Kyotaro Horiguchi wrote:
At Tue, 5 Oct 2021 00:59:46 +0900, Fujii Masao
wrote in
I think that it's better to comment why "retry" is not necessary
when not in standby mode.
---
When not in standby mode, an invalid page header should cause recovery
to
At Tue, 5 Oct 2021 00:59:46 +0900, Fujii Masao
wrote in
> I think that it's better to comment why "retry" is not necessary
> when not in standby mode.
>
> ---
> When not in standby mode, an invalid page header should cause recovery
> to end, not retry reading the page, so we
On 2021/09/13 17:21, Kyotaro Horiguchi wrote:
I wrote "while not in standby mode, we don't need to avoid retry the
entire record" but that doesn't mean the inversion "while in standby
mode, we need to do avoid that". In the first place retry doesn't
happen while not in standby mode. I don't
At Mon, 13 Sep 2021 17:21:31 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Mon, 13 Sep 2021 14:56:11 +0900, Fujii Masao
> wrote in
> >
> >
> > On 2021/09/13 11:00, Kyotaro Horiguchi wrote:
> > > The point here is "retry this page, not this record", so "we don't
> > > need
> > > to retry
At Mon, 13 Sep 2021 14:56:11 +0900, Fujii Masao
wrote in
>
>
> On 2021/09/13 11:00, Kyotaro Horiguchi wrote:
> > The point here is "retry this page, not this record", so "we don't
> > need
> > to retry immediately" looks a bit ambiguous. So how about something
> > like this?
> > Note that we
On 2021/09/13 11:00, Kyotaro Horiguchi wrote:
The point here is "retry this page, not this record", so "we don't need
to retry immediately" looks a bit ambiguous. So how about something
like this?
Note that we don't do this while not in standby mode because we don't
need to avoid retrying
At Fri, 10 Sep 2021 10:38:39 +0900, Fujii Masao
wrote in
>
>
> On 2021/09/07 2:02, Fujii Masao wrote:
> > Even if we do this while NOT in standby mode, ISTM that this function
> > doesn't
> > return with a valid errmsg_buf because it's reset. So probably the
> > comment
> > should be updated
On 2021/09/07 2:02, Fujii Masao wrote:
Even if we do this while NOT in standby mode, ISTM that this function doesn't
return with a valid errmsg_buf because it's reset. So probably the comment
should be updated as follows?
-
We don't do this while not in standby mode
On 2021/09/06 3:11, Alvaro Herrera wrote:
On 2021-Sep-03, Kyotaro Horiguchi wrote:
diff --git a/src/backend/access/transam/xlog.c
b/src/backend/access/transam/xlog.c
index 24165ab03e..b621ad6b0f 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@
On 2021-Sep-03, Kyotaro Horiguchi wrote:
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> index 24165ab03e..b621ad6b0f 100644
> --- a/src/backend/access/transam/xlog.c
> +++ b/src/backend/access/transam/xlog.c
> @@ -12496,9 +12496,21 @@ retry:
>*
>
At Fri, 03 Sep 2021 16:55:36 +0900 (JST), Kyotaro Horiguchi
wrote in
> > Yes, I'm fine with your latest patch.
>
> Thanks. Maybe some additional comment is needed.
Something like this.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git
At Thu, 2 Sep 2021 21:52:00 +0900, Fujii Masao
wrote in
>
>
> On 2021/09/02 16:26, Kyotaro Horiguchi wrote:
> > I believe errmsg_buf is an interface to emit error messages dedicated
> > to xlogreader that doesn't have an access to elog facility, and
> > xlogreader doesn't (or ought not to or
On 2021/09/02 16:26, Kyotaro Horiguchi wrote:
I believe errmsg_buf is an interface to emit error messages dedicated
to xlogreader that doesn't have an access to elog facility, and
xlogreader doesn't (or ought not to or expect to) suppose
non-xlogreader callback functions set the variable. In
At Thu, 2 Sep 2021 14:44:31 +0900, Fujii Masao
wrote in
>
>
> On 2021/09/02 13:17, Kyotaro Horiguchi wrote:
> > Did you read the comment just above?
>
> Yes!
Glad to hear that, or..:p
> > xlog.c:12523
> >> * Check the page header immediately, so that we can retry immediately
> >> if
>
On 2021/09/02 13:17, Kyotaro Horiguchi wrote:
Did you read the comment just above?
Yes!
xlog.c:12523
* Check the page header immediately, so that we can retry immediately
if
* it's not valid. This may seem unnecessary, because XLogReadRecord()
* validates the
(.. sorry for the chained-mails)
At Thu, 02 Sep 2021 13:31:31 +0900 (JST), Kyotaro Horiguchi
wrote in
> Sorry, please let me add something.
>
> At Thu, 02 Sep 2021 13:17:16 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Thu, 2 Sep 2021 12:19:25 +0900, Fujii Masao
> > wrote in
> > >
Sorry, please let me add something.
At Thu, 02 Sep 2021 13:17:16 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 2 Sep 2021 12:19:25 +0900, Fujii Masao
> wrote in
> > Also I'm tempted to move ereport() and reset of errmsg_buf to
> > under next_record_is_invalid as follows. That is, in
At Thu, 2 Sep 2021 12:19:25 +0900, Fujii Masao
wrote in
>
>
> On 2021/07/19 18:52, Yugo NAGATA wrote:
> > Well, I think my first patch was not wrong. The difference with the
> > latest
> > patch is just whether we perform the additional check when we are not
> > in
> > standby mode or not.
On 2021/07/19 18:52, Yugo NAGATA wrote:
Well, I think my first patch was not wrong. The difference with the latest
patch is just whether we perform the additional check when we are not in
standby mode or not. The behavior is basically the same although which function
detects and prints the
On Mon, 19 Jul 2021 06:32:28 -0300
Ranier Vilela wrote:
> Em seg., 19 de jul. de 2021 às 06:15, Yugo NAGATA
> escreveu:
>
> > On Mon, 19 Jul 2021 17:47:07 +0900 (JST)
> > Kyotaro Horiguchi wrote:
> >
> > > At Mon, 19 Jul 2021 16:00:39 +0900, Yugo NAGATA
> > wrote in
> > > > Your patch
Em seg., 19 de jul. de 2021 às 06:15, Yugo NAGATA
escreveu:
> On Mon, 19 Jul 2021 17:47:07 +0900 (JST)
> Kyotaro Horiguchi wrote:
>
> > At Mon, 19 Jul 2021 16:00:39 +0900, Yugo NAGATA
> wrote in
> > > Your patch doesn't fix the issue that the error message is never
> reported in
> > > standby
On Mon, 19 Jul 2021 17:47:07 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Mon, 19 Jul 2021 16:00:39 +0900, Yugo NAGATA wrote
> in
> > Your patch doesn't fix the issue that the error message is never reported in
> > standby mode. When a WAL page header is broken, the standby would silently
> >
me> Howeer, I'm still on the opinion that we don't need to check that
me> while in standby mode.
Of course it's typo of "while not in standby mode".
sorry..
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Mon, 19 Jul 2021 16:00:39 +0900, Yugo NAGATA wrote in
> Your patch doesn't fix the issue that the error message is never reported in
> standby mode. When a WAL page header is broken, the standby would silently
> repeat
> retrying forever.
Ok, I see your point and agree to that.
> I think
On Mon, 19 Jul 2021 15:14:41 +0900 (JST)
Kyotaro Horiguchi wrote:
> Hello.
>
> At Sun, 18 Jul 2021 04:55:05 +0900, Yugo NAGATA wrote
> in
> > Hello,
> >
> > I found that any corruption of WAL page header found during recovery is
> > never
> > reported in log messages. If wal page header is
Hello.
At Sun, 18 Jul 2021 04:55:05 +0900, Yugo NAGATA wrote in
> Hello,
>
> I found that any corruption of WAL page header found during recovery is never
> reported in log messages. If wal page header is broken, it is detected in
> XLogReaderValidatePageHeader called from XLogPageRead, but
On Sat, 17 Jul 2021 18:40:02 -0300
Ranier Vilela wrote:
> Em sáb., 17 de jul. de 2021 às 16:57, Yugo NAGATA
> escreveu:
>
> > Hello,
> >
> > I found that any corruption of WAL page header found during recovery is
> > never
> > reported in log messages. If wal page header is broken, it is
Em sáb., 17 de jul. de 2021 às 16:57, Yugo NAGATA
escreveu:
> Hello,
>
> I found that any corruption of WAL page header found during recovery is
> never
> reported in log messages. If wal page header is broken, it is detected in
> XLogReaderValidatePageHeader called from XLogPageRead, but the
Hello,
I found that any corruption of WAL page header found during recovery is never
reported in log messages. If wal page header is broken, it is detected in
XLogReaderValidatePageHeader called from XLogPageRead, but the error messages
are always reset and never reported.
if
29 matches
Mail list logo
