public inbox for [email protected]
help / color / mirror / Atom feedMake mesage at end-of-recovery less scary.
35+ messages / 13 participants
[nested] [flat]
* Make mesage at end-of-recovery less scary.
@ 2020-02-28 07:01 Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Kyotaro Horiguchi @ 2020-02-28 07:01 UTC (permalink / raw)
To: [email protected]
Hello, this is a followup thread of [1].
# I didn't noticed that the thread didn't cover -hackers..
When recovery of any type ends, we see several kinds of error messages
that says "WAL is broken".
> LOG: invalid record length at 0/7CB6BC8: wanted 24, got 0
> LOG: redo is not required
> LOG: database system is ready to accept connections
This patch reduces the scariness of such messages as the follows.
> LOG: rached end of WAL at 0/1551048 on timeline 1 in pg_wal during crash recovery
> DETAIL: invalid record length at 0/1551048: wanted 24, got 0
> LOG: redo is not required
> LOG: database system is ready to accept connections
[1] https://www.postgresql.org/message-id/20200117.172655.1384889922565817808.horikyota.ntt%40gmail.com
I'll register this to the coming CF.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2020-02-28 07:33 Michael Paquier <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Michael Paquier @ 2020-02-28 07:33 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]
On Fri, Feb 28, 2020 at 04:01:00PM +0900, Kyotaro Horiguchi wrote:
> Hello, this is a followup thread of [1].
>
> # I didn't noticed that the thread didn't cover -hackers..
>
> When recovery of any type ends, we see several kinds of error messages
> that says "WAL is broken".
Have you considered an error context here? Your patch leads to a bit
of duplication with the message a bit down of what you are changing
where the end of local pg_wal is reached.
> + * reached the end of WAL. Otherwise something's really wrong and
> + * we report just only the errormsg if any. If we don't receive
This sentence sounds strange to me. Or you meant "Something is wrong,
so use errormsg as report if it is set"?
> + * Note: errormsg is alreay translated.
Typo here.
> + if (StandbyMode)
> + ereport(actual_emode,
> + (errmsg ("rached end of WAL at %X/%X on timeline %u in %s during streaming replication",
StandbyMode happens also with only WAL archiving, depending on if
primary_conninfo is set or not.
> + (errmsg ("rached end of WAL at %X/%X on timeline %u in %s during crash recovery",
FWIW, you are introducing three times the same typo, in the same
word, in three different messages.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2020-02-28 08:28 Kyotaro Horiguchi <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Kyotaro Horiguchi @ 2020-02-28 08:28 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
Thank you for the comments.
At Fri, 28 Feb 2020 16:33:18 +0900, Michael Paquier <[email protected]> wrote in
> On Fri, Feb 28, 2020 at 04:01:00PM +0900, Kyotaro Horiguchi wrote:
> > Hello, this is a followup thread of [1].
> >
> > # I didn't noticed that the thread didn't cover -hackers..
> >
> > When recovery of any type ends, we see several kinds of error messages
> > that says "WAL is broken".
>
> Have you considered an error context here? Your patch leads to a bit
> of duplication with the message a bit down of what you are changing
> where the end of local pg_wal is reached.
It is a DEBUG message and it is for the time moving from crash
recovery to archive recovery. I could remove that but decided to leave
it for tracability.
> > + * reached the end of WAL. Otherwise something's really wrong and
> > + * we report just only the errormsg if any. If we don't receive
>
> This sentence sounds strange to me. Or you meant "Something is wrong,
> so use errormsg as report if it is set"?
The whole comment there follows.
| recovery. If we get here during recovery, we can assume that we
| reached the end of WAL. Otherwise something's really wrong and
| we report just only the errormsg if any. If we don't receive
| errormsg here, we already logged something. We don't emit
| "reached end of WAL" in muted messages.
"Othhersise" means "other than the case of recovery". "Just only the
errmsg" means "show the message not as a part the message "reached end
of WAL".
> > + * Note: errormsg is alreay translated.
>
> Typo here.
Thanks. Will fix along with "rached".
> > + if (StandbyMode)
> > + ereport(actual_emode,
> > + (errmsg ("rached end of WAL at %X/%X on timeline %u in %s during streaming replication",
>
> StandbyMode happens also with only WAL archiving, depending on if
> primary_conninfo is set or not.
Right. I'll fix it. Maybe to "during standby mode".
> > + (errmsg ("rached end of WAL at %X/%X on timeline %u in %s during crash recovery",
>
> FWIW, you are introducing three times the same typo, in the same
> word, in three different messages.
They're copy-pasto. I refrained from constructing an error message
from multiple nonindipendent parts. Are you suggesting to do so?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2020-03-05 07:06 Kyotaro Horiguchi <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Kyotaro Horiguchi @ 2020-03-05 07:06 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
Hello.
I changed the condition from randAccess to fetching_ckpt considering
the discussion in another thread [1]. Then I moved the block that
shows the new messages to more appropriate place.
At Fri, 28 Feb 2020 17:28:06 +0900 (JST), Kyotaro Horiguchi <[email protected]> wrote in
> >
> > Have you considered an error context here? Your patch leads to a bit
> > of duplication with the message a bit down of what you are changing
> > where the end of local pg_wal is reached.
>
> It is a DEBUG message and it is for the time moving from crash
> recovery to archive recovery. I could remove that but decided to leave
> it for tracability.
I modified the message so that it has the same look to the new
messages, but I left it being DEBUG1, since it is just a intermediate
state. We should finally see one of the new three messages.
After the messages changed, another message from wal sender came to
look redundant.
| [20866] LOG: replication terminated by primary server
| [20866] DETAIL: End of WAL reached on timeline 1 at 0/30001C8.
| [20866] FATAL: could not send end-of-streaming message to primary: no COPY in progress
| [20851] LOG: reached end of WAL at 0/30001C8 on timeline 1 in archive during standby mode
| [20851] DETAIL: invalid record length at 0/30001C8: wanted 24, got 0
I changed the above to the below, which looks more adequate.
| [24271] LOG: replication terminated by primary server on timeline 1 at 0/3000240.
| [24271] FATAL: could not send end-of-streaming message to primary: no COPY in progress
| [24267] LOG: reached end of WAL at 0/3000240 on timeline 1 in archive during standby mode
| [24267] DETAIL: invalid record length at 0/3000240: wanted 24, got 0
> > > + * reached the end of WAL. Otherwise something's really wrong and
> > > + * we report just only the errormsg if any. If we don't receive
> >
> > This sentence sounds strange to me. Or you meant "Something is wrong,
> > so use errormsg as report if it is set"?
The message no longer exists.
> > > + (errmsg ("rached end of WAL at %X/%X on timeline %u in %s during crash recovery",
> >
> > FWIW, you are introducing three times the same typo, in the same
> > word, in three different messages.
>
> They're copy-pasto. I refrained from constructing an error message
> from multiple nonindipendent parts. Are you suggesting to do so?
The tree times repetition of almost same phrases is very unreadable. I
rewrote it in more simple shape.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2020-03-23 09:37 Peter Eisentraut <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
0 siblings, 2 replies; 35+ messages in thread
From: Peter Eisentraut @ 2020-03-23 09:37 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; [email protected]; +Cc: [email protected]
On 2020-03-05 08:06, Kyotaro Horiguchi wrote:
> | [20866] LOG: replication terminated by primary server
> | [20866] DETAIL: End of WAL reached on timeline 1 at 0/30001C8.
> | [20866] FATAL: could not send end-of-streaming message to primary: no COPY in progress
> | [20851] LOG: reached end of WAL at 0/30001C8 on timeline 1 in archive during standby mode
> | [20851] DETAIL: invalid record length at 0/30001C8: wanted 24, got 0
>
> I changed the above to the below, which looks more adequate.
>
> | [24271] LOG: replication terminated by primary server on timeline 1 at 0/3000240.
> | [24271] FATAL: could not send end-of-streaming message to primary: no COPY in progress
> | [24267] LOG: reached end of WAL at 0/3000240 on timeline 1 in archive during standby mode
> | [24267] DETAIL: invalid record length at 0/3000240: wanted 24, got 0
Is this the before and after? That doesn't seem like a substantial
improvement to me. You still get the "scary" message at the end.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2020-03-23 17:43 Ashwin Agrawal <[email protected]>
parent: Peter Eisentraut <[email protected]>
1 sibling, 1 reply; 35+ messages in thread
From: Ashwin Agrawal @ 2020-03-23 17:43 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Kyotaro Horiguchi <[email protected]>; Michael Paquier <[email protected]>; PostgreSQL Hackers <[email protected]>
On Mon, Mar 23, 2020 at 2:37 AM Peter Eisentraut <
[email protected]> wrote:
> On 2020-03-05 08:06, Kyotaro Horiguchi wrote:
> > | [20866] LOG: replication terminated by primary server
> > | [20866] DETAIL: End of WAL reached on timeline 1 at 0/30001C8.
> > | [20866] FATAL: could not send end-of-streaming message to primary: no
> COPY in progress
> > | [20851] LOG: reached end of WAL at 0/30001C8 on timeline 1 in archive
> during standby mode
> > | [20851] DETAIL: invalid record length at 0/30001C8: wanted 24, got 0
> >
> > I changed the above to the below, which looks more adequate.
> >
> > | [24271] LOG: replication terminated by primary server on timeline 1
> at 0/3000240.
> > | [24271] FATAL: could not send end-of-streaming message to primary:
> no COPY in progress
> > | [24267] LOG: reached end of WAL at 0/3000240 on timeline 1 in
> archive during standby mode
> > | [24267] DETAIL: invalid record length at 0/3000240: wanted 24, got 0
>
> Is this the before and after? That doesn't seem like a substantial
> improvement to me. You still get the "scary" message at the end.
>
+1 I agree it still reads scary and doesn't seem improvement.
Plus, I am hoping message will improve for pg_waldump as well?
Since it reads confusing and every-time have to explain new developer it's
expected behavior which is annoying.
pg_waldump: fatal: error in WAL record at 0/1553F70: invalid record length
at 0/1553FA8: wanted 24, got 0
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2020-03-23 19:47 Andres Freund <[email protected]>
parent: Peter Eisentraut <[email protected]>
1 sibling, 1 reply; 35+ messages in thread
From: Andres Freund @ 2020-03-23 19:47 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Kyotaro Horiguchi <[email protected]>; [email protected]; [email protected]
Hi,
On 2020-03-23 10:37:16 +0100, Peter Eisentraut wrote:
> On 2020-03-05 08:06, Kyotaro Horiguchi wrote:
> > | [20866] LOG: replication terminated by primary server
> > | [20866] DETAIL: End of WAL reached on timeline 1 at 0/30001C8.
> > | [20866] FATAL: could not send end-of-streaming message to primary: no COPY in progress
IMO it's a bug that we see this FATAL. I seem to recall that we didn't
use to get that?
> > | [20851] LOG: reached end of WAL at 0/30001C8 on timeline 1 in archive during standby mode
> > | [20851] DETAIL: invalid record length at 0/30001C8: wanted 24, got 0
> >
> > I changed the above to the below, which looks more adequate.
> >
> > | [24271] LOG: replication terminated by primary server on timeline 1 at 0/3000240.
> > | [24271] FATAL: could not send end-of-streaming message to primary: no COPY in progress
> > | [24267] LOG: reached end of WAL at 0/3000240 on timeline 1 in archive during standby mode
> > | [24267] DETAIL: invalid record length at 0/3000240: wanted 24, got 0
>
> Is this the before and after? That doesn't seem like a substantial
> improvement to me. You still get the "scary" message at the end.
It seems like a minor improvement - folding the DETAIL into the message
makes sense to me here. But it indeed doesn't really address the main
issue.
I think we don't want to elide the information about how the end of the
WAL was detected - there are some issues where I found that quite
helpful. But we could reformulate it to be clearer that it's informative
output, not a bug. E.g. something roughly like
LOG: reached end of WAL at 0/3000240 on timeline 1 in archive during standby mode
DETAIL: End detected due to invalid record length at 0/3000240: expected 24, got 0
(I first elided the position in the DETAIL, but it could differ from the
one in LOG)
I don't find that very satisfying, but I can't come up with something
that provides the current information, while being less scary than my
suggestion?
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2020-03-23 19:49 Andres Freund <[email protected]>
parent: Ashwin Agrawal <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Andres Freund @ 2020-03-23 19:49 UTC (permalink / raw)
To: Ashwin Agrawal <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Kyotaro Horiguchi <[email protected]>; Michael Paquier <[email protected]>; PostgreSQL Hackers <[email protected]>
Hi,
On 2020-03-23 10:43:09 -0700, Ashwin Agrawal wrote:
> Plus, I am hoping message will improve for pg_waldump as well?
> Since it reads confusing and every-time have to explain new developer it's
> expected behavior which is annoying.
>
> pg_waldump: fatal: error in WAL record at 0/1553F70: invalid record length
> at 0/1553FA8: wanted 24, got 0
What would you like to see here? There's inherently a lot less
information about the context in waldump. We can't know whether it's to
be expected that the WAL ends at that point, or whether there was
corruption.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2020-03-24 01:52 Kyotaro Horiguchi <[email protected]>
parent: Andres Freund <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Kyotaro Horiguchi @ 2020-03-24 01:52 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]
At Mon, 23 Mar 2020 12:47:36 -0700, Andres Freund <[email protected]> wrote in
> Hi,
>
> On 2020-03-23 10:37:16 +0100, Peter Eisentraut wrote:
> > On 2020-03-05 08:06, Kyotaro Horiguchi wrote:
> > > | [20866] LOG: replication terminated by primary server
> > > | [20866] DETAIL: End of WAL reached on timeline 1 at 0/30001C8.
> > > | [20866] FATAL: could not send end-of-streaming message to primary: no COPY in progress
>
> IMO it's a bug that we see this FATAL. I seem to recall that we didn't
> use to get that?
I thought that it is a convention that A auxiliary process uses ERROR
(which is turned into FATAL in ereport) to exit, which I didn't like
so much, but it was out of scope of this patch.
As for the message bove, the FATAL is preceded by the "LOG:
replication terminated by" message, that means walreceiver tries to
send new data after disconnection just to fail, which is
unreasonable. I think we should exit immediately after detecting
disconnection. The FATAL is gone by the attached.
> > > | [24267] LOG: reached end of WAL at 0/3000240 on timeline 1 in archive during standby mode
> > > | [24267] DETAIL: invalid record length at 0/3000240: wanted 24, got 0
> >
> > Is this the before and after? That doesn't seem like a substantial
> > improvement to me. You still get the "scary" message at the end.
>
> It seems like a minor improvement - folding the DETAIL into the message
> makes sense to me here. But it indeed doesn't really address the main
> issue.
>
> I think we don't want to elide the information about how the end of the
> WAL was detected - there are some issues where I found that quite
> helpful. But we could reformulate it to be clearer that it's informative
> output, not a bug. E.g. something roughly like
>
> LOG: reached end of WAL at 0/3000240 on timeline 1 in archive during standby mode
> DETAIL: End detected due to invalid record length at 0/3000240: expected 24, got 0
> (I first elided the position in the DETAIL, but it could differ from the
> one in LOG)
>
> I don't find that very satisfying, but I can't come up with something
> that provides the current information, while being less scary than my
> suggestion?
The 0-length record is not an "invalid" state during recovery, so we
can add the message for the state as "record length is 0 at %X/%X". I
think if other states found there, it implies something wrong.
LSN is redundantly shown but I'm not sure if it is better to remove it
from either of the two lines.
| LOG: reached end of WAL at 0/3000850 on timeline 1 in pg_wal during crash recovery
| DETAIL: record length is 0 at 0/3000850
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2020-03-25 12:53 Peter Eisentraut <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Peter Eisentraut @ 2020-03-25 12:53 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; [email protected]; +Cc: [email protected]; [email protected]
On 2020-03-24 02:52, Kyotaro Horiguchi wrote:
>> I don't find that very satisfying, but I can't come up with something
>> that provides the current information, while being less scary than my
>> suggestion?
> The 0-length record is not an "invalid" state during recovery, so we
> can add the message for the state as "record length is 0 at %X/%X". I
> think if other states found there, it implies something wrong.
>
> LSN is redundantly shown but I'm not sure if it is better to remove it
> from either of the two lines.
>
> | LOG: reached end of WAL at 0/3000850 on timeline 1 in pg_wal during crash recovery
> | DETAIL: record length is 0 at 0/3000850
I'm not up to date on all these details, but my high-level idea would be
some kind of hint associated with the existing error messages, like:
HINT: This is to be expected if this is the end of the WAL. Otherwise,
it could indicate corruption.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2020-03-26 16:40 Robert Haas <[email protected]>
parent: Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Robert Haas @ 2020-03-26 16:40 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Kyotaro Horiguchi <[email protected]>; Andres Freund <[email protected]>; Michael Paquier <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 25, 2020 at 8:53 AM Peter Eisentraut
<[email protected]> wrote:
> HINT: This is to be expected if this is the end of the WAL. Otherwise,
> it could indicate corruption.
First, I agree that this general issue is a problem, because it's come
up for me in quite a number of customer situations. Either people get
scared when they shouldn't, because the message is innocuous, or they
don't get scared about other things that actually are scary, because
if some scary-looking messages are actually innocuous, it can lead
people to believe that the same is true in other cases.
Second, I don't really like the particular formulation you have above,
because the user still doesn't know whether or not to be scared. Can
we figure that out? I think if we're in crash recovery, I think that
we should not be scared, because we have no alternative to assuming
that we've reached the end of WAL, so all crash recoveries will end
like this. If we're in archive recovery, we should definitely be
scared if we haven't yet reached the minimum recovery point, because
more WAL than that should certainly exist. After that, it depends on
how we got the WAL. If it's being streamed, the question is whether
we've reached the end of what got streamed. If it's being copied from
the archive, we ought to have the whole segment, but maybe not more.
Can we get the right context to the point where the error is being
reported to know whether we hit the error at the end of the WAL that
was streamed? If not, can we somehow rejigger things so that we only
make it sound scary if we keep getting stuck at the same point when we
woud've expected to make progress meanwhile?
I'm just spitballing here, but it would be really good if there's a
way to know definitely whether or not you should be scared. Corrupted
WAL segments are definitely a thing that happens, but retries are a
lot more common.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2020-03-28 02:25 James Coleman <[email protected]>
parent: Robert Haas <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: James Coleman @ 2020-03-28 02:25 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Kyotaro Horiguchi <[email protected]>; Andres Freund <[email protected]>; Michael Paquier <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Mar 26, 2020 at 12:41 PM Robert Haas <[email protected]> wrote:
>
> On Wed, Mar 25, 2020 at 8:53 AM Peter Eisentraut
> <[email protected]> wrote:
> > HINT: This is to be expected if this is the end of the WAL. Otherwise,
> > it could indicate corruption.
>
> First, I agree that this general issue is a problem, because it's come
> up for me in quite a number of customer situations. Either people get
> scared when they shouldn't, because the message is innocuous, or they
> don't get scared about other things that actually are scary, because
> if some scary-looking messages are actually innocuous, it can lead
> people to believe that the same is true in other cases.
>
> Second, I don't really like the particular formulation you have above,
> because the user still doesn't know whether or not to be scared. Can
> we figure that out? I think if we're in crash recovery, I think that
> we should not be scared, because we have no alternative to assuming
> that we've reached the end of WAL, so all crash recoveries will end
> like this. If we're in archive recovery, we should definitely be
> scared if we haven't yet reached the minimum recovery point, because
> more WAL than that should certainly exist. After that, it depends on
> how we got the WAL. If it's being streamed, the question is whether
> we've reached the end of what got streamed. If it's being copied from
> the archive, we ought to have the whole segment, but maybe not more.
> Can we get the right context to the point where the error is being
> reported to know whether we hit the error at the end of the WAL that
> was streamed? If not, can we somehow rejigger things so that we only
> make it sound scary if we keep getting stuck at the same point when we
> woud've expected to make progress meanwhile?
>
> I'm just spitballing here, but it would be really good if there's a
> way to know definitely whether or not you should be scared. Corrupted
> WAL segments are definitely a thing that happens, but retries are a
> lot more common.
First, I agree that getting enough context to say precisely is by far the ideal.
That being said, as an end user who's found this surprising -- and
momentarily scary every time I initially scan it even though I *know
intellectually it's not* -- I would find Peter's suggestion a
significant improvement over what we have now. I'm fairly certainly my
co-workers on our database team would also. Knowing that something is
at least not always scary is good. Though I'll grant that this does
have the negative in reverse: if it actually is a scary
situation...this mutes your concern level. On the other hand,
monitoring would tell us if there's a real problem (namely replication
lag), so I think the trade-off is clearly worth it.
How about this minor tweak:
HINT: This is expected if this is the end of currently available WAL.
Otherwise, it could indicate corruption.
Thanks,
James
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2021-03-03 16:14 David Steele <[email protected]>
parent: James Coleman <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: David Steele @ 2021-03-03 16:14 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; Michael Paquier <[email protected]>; PostgreSQL Hackers <[email protected]>; James Coleman <[email protected]>; Robert Haas <[email protected]>
Hi Kyotaro,
On 3/27/20 10:25 PM, James Coleman wrote:
> On Thu, Mar 26, 2020 at 12:41 PM Robert Haas <[email protected]> wrote:
>>
>> I'm just spitballing here, but it would be really good if there's a
>> way to know definitely whether or not you should be scared. Corrupted
>> WAL segments are definitely a thing that happens, but retries are a
>> lot more common.
>
> First, I agree that getting enough context to say precisely is by far the ideal.
>
> That being said, as an end user who's found this surprising -- and
> momentarily scary every time I initially scan it even though I *know
> intellectually it's not* -- I would find Peter's suggestion a
> significant improvement over what we have now. I'm fairly certainly my
> co-workers on our database team would also. Knowing that something is
> at least not always scary is good. Though I'll grant that this does
> have the negative in reverse: if it actually is a scary
> situation...this mutes your concern level. On the other hand,
> monitoring would tell us if there's a real problem (namely replication
> lag), so I think the trade-off is clearly worth it.
>
> How about this minor tweak:
> HINT: This is expected if this is the end of currently available WAL.
> Otherwise, it could indicate corruption.
Any thoughts on the suggestions for making the messaging clearer?
Also, the patch no longer applies:
http://cfbot.cputube.org/patch_32_2490.log.
Marking this Waiting on Author.
Regards,
--
-David
[email protected]
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2021-03-04 06:50 Kyotaro Horiguchi <[email protected]>
parent: David Steele <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Kyotaro Horiguchi @ 2021-03-04 06:50 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
At Wed, 3 Mar 2021 11:14:20 -0500, David Steele <[email protected]> wrote in
> Hi Kyotaro,
>
> On 3/27/20 10:25 PM, James Coleman wrote:
> > On Thu, Mar 26, 2020 at 12:41 PM Robert Haas <[email protected]>
> > wrote:
> >>
> >> I'm just spitballing here, but it would be really good if there's a
> >> way to know definitely whether or not you should be scared. Corrupted
> >> WAL segments are definitely a thing that happens, but retries are a
> >> lot more common.
> > First, I agree that getting enough context to say precisely is by far
> > the ideal.
> > That being said, as an end user who's found this surprising -- and
> > momentarily scary every time I initially scan it even though I *know
> > intellectually it's not* -- I would find Peter's suggestion a
> > significant improvement over what we have now. I'm fairly certainly my
> > co-workers on our database team would also. Knowing that something is
> > at least not always scary is good. Though I'll grant that this does
> > have the negative in reverse: if it actually is a scary
> > situation...this mutes your concern level. On the other hand,
> > monitoring would tell us if there's a real problem (namely replication
> > lag), so I think the trade-off is clearly worth it.
> > How about this minor tweak:
> > HINT: This is expected if this is the end of currently available WAL.
> > Otherwise, it could indicate corruption.
>
> Any thoughts on the suggestions for making the messaging clearer?
>
> Also, the patch no longer applies:
> http://cfbot.cputube.org/patch_32_2490.log.
Sorry for missing the last discussions. I agree to the point about
really-scary situation.
ValidXLogRecordHeader deliberately marks End-Of-WAL only in the case
of zero-length record so that the callers can identify that case,
instead of inferring the EOW state without it. All other invalid data
is treated as potentially danger situation. I think this is a
reasonable classification. And the error level for the "danger" cases
is changed to WARNING (from LOG).
As the result, the following messages are emitted with the attached.
- found zero-length record during recovery (the DETAIL might not be needed.)
> LOG: redo starts at 0/14000118
> LOG: reached end of WAL at 0/14C5D070 on timeline 1 in pg_wal during crash recovery
> DETAIL: record length is 0 at 0/14C5D070
> LOG: redo done at 0/14C5CF48 system usage: ...
- found another kind of invalid data
> LOG: redo starts at 0/150000A0
> WARNING: invalid record length at 0/1500CA60: wanted 24, got 54
> LOG: redo done at 0/1500CA28 system usage: ...
On the way checking the patch, I found that it emits the following log
lines in the case the redo loop meets an invalid record at the
starting:
> LOG: invalid record length at 0/10000118: wanted 24, got 42
> LOG: redo is not required
which doesn't look proper. That case is identifiable using the
End-of_WAL flag this patch adds. Thus we get the following error
messages.
- found end-of-wal at the beginning of recovery
> LOG: reached end of WAL at 0/130000A0 on timeline 1 in pg_wal during crash recovery
> DETAIL: record length is 0 at 0/130000A0
> LOG: redo is not required
- found invalid data
> WARNING: invalid record length at 0/120000A0: wanted 24, got 42
> WARNING: redo is skipped
> HINT: This suggests WAL file corruption. You might need to check the database.
The logic of ErrRecPtr in ReadRecord may wrong. I remember having
such an discussion before...
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2021-10-22 17:54 Bossart, Nathan <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Bossart, Nathan @ 2021-10-22 17:54 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; [email protected] <[email protected]>; +Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>
On 3/4/21, 10:50 PM, "Kyotaro Horiguchi" <[email protected]> wrote:
> As the result, the following messages are emitted with the attached.
I'd like to voice my support for this effort, and I intend to help
review the patch. It looks like the latest patch no longer applies,
so I've marked the commitfest entry [0] as waiting-on-author.
Nathan
[0] https://commitfest.postgresql.org/35/2490/
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2021-11-08 05:59 Kyotaro Horiguchi <[email protected]>
parent: Bossart, Nathan <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Kyotaro Horiguchi @ 2021-11-08 05:59 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
At Fri, 22 Oct 2021 17:54:40 +0000, "Bossart, Nathan" <[email protected]> wrote in
> On 3/4/21, 10:50 PM, "Kyotaro Horiguchi" <[email protected]> wrote:
> > As the result, the following messages are emitted with the attached.
>
> I'd like to voice my support for this effort, and I intend to help
> review the patch. It looks like the latest patch no longer applies,
> so I've marked the commitfest entry [0] as waiting-on-author.
>
> Nathan
>
> [0] https://commitfest.postgresql.org/35/2490/
Sorry for being late to reply. I rebased this to the current master.
- rebased
- use LSN_FORMAT_ARGS instead of bare shift and mask.
- v4 immediately exited walreceiver on disconnection. Maybe I wanted
not to see a FATAL message on standby after primary dies. However
that would be another issue and that change was plain wrong.. v5
just removes the "end-of-WAL" part from the message, which duplicate
to what startup emits.
- add a new error message "missing contrecord at %X/%X". Maybe this
should be regarded as a leftover of the contrecord patch. In the
attached patch the "%X/%X" is the LSN of the current record. The log
messages look like this (026_overwrite_contrecord).
LOG: redo starts at 0/1486CB8
WARNING: missing contrecord at 0/1FFC2E0
LOG: consistent recovery state reached at 0/1FFC2E0
LOG: started streaming WAL from primary at 0/2000000 on timeline 1
LOG: successfully skipped missing contrecord at 0/1FFC2E0, overwritten at 2021-11-08 14:50:11.969952+09
CONTEXT: WAL redo at 0/2000028 for XLOG/OVERWRITE_CONTRECORD: lsn 0/1FFC2E0; time 2021-11-08 14:50:11.969952+09
While checking the behavior for the case of missing-contrecord, I
noticed that emode_for_corrupt_record() doesn't work as expected since
readSource is reset to XLOG_FROM_ANY after a read failure. We could
remember the last failed source but pg_wal should have been visited if
page read error happened so I changed the function so that it treats
XLOG_FROM_ANY the same way with XLOG_FROM_PG_WAL.
(Otherwise we see "LOG: reached end-of-WAL at .." message after
"WARNING: missing contrecord at.." message.)
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2021-11-09 00:53 Michael Paquier <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Michael Paquier @ 2021-11-09 00:53 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
On Mon, Nov 08, 2021 at 02:59:46PM +0900, Kyotaro Horiguchi wrote:
> While checking the behavior for the case of missing-contrecord, I
> noticed that emode_for_corrupt_record() doesn't work as expected since
> readSource is reset to XLOG_FROM_ANY after a read failure. We could
> remember the last failed source but pg_wal should have been visited if
> page read error happened so I changed the function so that it treats
> XLOG_FROM_ANY the same way with XLOG_FROM_PG_WAL.
FWIW, I am not much a fan of assuming that it is fine to use
XLOG_FROM_ANY as a condition here. The comments on top of
emode_for_corrupt_record() make it rather clear what the expectations
are, and this is the default readSource.
> (Otherwise we see "LOG: reached end-of-WAL at .." message after
> "WARNING: missing contrecord at.." message.)
+ /* broken record found */
+ ereport(WARNING,
+ (errmsg("redo is skipped"),
+ errhint("This suggests WAL file corruption. You might need to check the database.")));
This looks rather scary to me, FWIW, and this could easily be reached
if one forgets about EndOfWAL while hacking on xlogreader.c.
Unlikely so, still.
+ report_invalid_record(state,
+ "missing contrecord at %X/%X",
+ LSN_FORMAT_ARGS(RecPtr));
Isn't there a risk here to break applications checking after error
messages stored in the WAL reader after seeing a contrecord?
+ if (record->xl_tot_len == 0)
+ {
+ /* This is strictly not an invalid state, so phrase it as so. */
+ report_invalid_record(state,
+ "record length is 0 at %X/%X",
+ LSN_FORMAT_ARGS(RecPtr));
+ state->EndOfWAL = true;
+ return false;
+ }
This assumes that a value of 0 for xl_tot_len is a synonym of the end
of WAL, but cannot we have also a corrupted record in this case in the
shape of xl_tot_len being 0? We validate the full record after
reading the header, so it seems to me that we should not assume that
things are just ending as proposed in this patch.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2021-11-09 07:27 Kyotaro Horiguchi <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Kyotaro Horiguchi @ 2021-11-09 07:27 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Thank you for the comments!
At Tue, 9 Nov 2021 09:53:15 +0900, Michael Paquier <[email protected]> wrote in
> On Mon, Nov 08, 2021 at 02:59:46PM +0900, Kyotaro Horiguchi wrote:
> > While checking the behavior for the case of missing-contrecord, I
> > noticed that emode_for_corrupt_record() doesn't work as expected since
> > readSource is reset to XLOG_FROM_ANY after a read failure. We could
> > remember the last failed source but pg_wal should have been visited if
> > page read error happened so I changed the function so that it treats
> > XLOG_FROM_ANY the same way with XLOG_FROM_PG_WAL.
>
> FWIW, I am not much a fan of assuming that it is fine to use
> XLOG_FROM_ANY as a condition here. The comments on top of
> emode_for_corrupt_record() make it rather clear what the expectations
> are, and this is the default readSource.
The readSource is expected by the function to be the failed source but
it goes back to XLOG_FROM_ANY on page read failure. So the function
*is* standing on the wrong assumption. I noticed that currentSource
holds the last accessed source (but forgot about that). So it is
exactly what we need here. No longer need to introduce the unclear
assumption by using it.
> > (Otherwise we see "LOG: reached end-of-WAL at .." message after
> > "WARNING: missing contrecord at.." message.)
>
> + /* broken record found */
> + ereport(WARNING,
> + (errmsg("redo is skipped"),
> + errhint("This suggests WAL file corruption. You might need to check the database.")));
> This looks rather scary to me, FWIW, and this could easily be reached
Yes, the message is intentionally scary, since we don't come here in
the case of clean WAL:)
> if one forgets about EndOfWAL while hacking on xlogreader.c.
> Unlikely so, still.
I don't understand. Isn't it the case of almost every feature?
The patch compells hackers to maintain the condition for recovery
being considered cleanly ended. If the last record doesn't meet the
condition, the WAL file should be considered having a
problem. However, I don't see the condition expanded to have another
term in future.
Even if someone including myself broke that condition, we will at
worst unwantedly see a scary message. And I believe almost all
hackers can easily find it a bug from the DETAILED message shown along
aside. I'm not sure such bugs could be found in development phase,
though..
> + report_invalid_record(state,
> + "missing contrecord at %X/%X",
> + LSN_FORMAT_ARGS(RecPtr));
> Isn't there a risk here to break applications checking after error
> messages stored in the WAL reader after seeing a contrecord?
I'm not sure you are mentioning the case where no message is stored
previously, or the case where already a message is stored. The former
is fine as the record is actually broken. But I was missing the latter
case. In this version I avoided to overwite the error message.
> + if (record->xl_tot_len == 0)
> + {
> + /* This is strictly not an invalid state, so phrase it as so. */
> + report_invalid_record(state,
> + "record length is 0 at %X/%X",
> + LSN_FORMAT_ARGS(RecPtr));
> + state->EndOfWAL = true;
> + return false;
> + }
> This assumes that a value of 0 for xl_tot_len is a synonym of the end
> of WAL, but cannot we have also a corrupted record in this case in the
> shape of xl_tot_len being 0? We validate the full record after
> reading the header, so it seems to me that we should not assume that
> things are just ending as proposed in this patch.
Yeah, it's the most serious concern to me. So I didn't hide the
detailed message in the "end-of-wal reached message".
> LOG: reached end of WAL at 0/512F198 on timeline 1 in pg_wal during crash recovery
> DETAIL: record length is 0 at 0/512F210
I believe everyone regards zero record length as fine unless something
wrong is seen afterwards. However, we can extend the check to the
whole record header. I think it is by far nearer to the perfect for
almost all cases. The attached emits the following message for the
good (true end-of-WAL) case.
> LOG: reached end of WAL at 0/512F4A0 on timeline 1 in pg_wal during crash recovery
> DETAIL: empty record header found at 0/512F518
If garbage bytes are found in the header area, the following log will
be left. I think we can have a better message here.
> WARNING: garbage record header at 0/2095458
> LOG: redo done at 0/2095430 system usage: CPU: user: 0.03 s, system: 0.01 s, elapsed: 0.04 s
This is the updated version.
- emode_for_currupt_record() now uses currentSource instead of
readSource.
- If zero record length is faced, make sure the whole header is zeroed
before deciding it as the end-of-WAL.
- Do not overwrite existig message when missing contrecord is
detected. The message added here is seen in the TAP test log
026_overwrite_contrecord_standby.log
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2021-12-08 07:01 Kyotaro Horiguchi <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Kyotaro Horiguchi @ 2021-12-08 07:01 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
At Tue, 09 Nov 2021 16:27:51 +0900 (JST), Kyotaro Horiguchi <[email protected]> wrote in
> This is the updated version.
>
> - emode_for_currupt_record() now uses currentSource instead of
> readSource.
>
> - If zero record length is faced, make sure the whole header is zeroed
> before deciding it as the end-of-WAL.
>
> - Do not overwrite existig message when missing contrecord is
> detected. The message added here is seen in the TAP test log
> 026_overwrite_contrecord_standby.log
d2ddfa681db27a138acb63c8defa8cc6fa588922 removed global variables
ReadRecPtr and EndRecPtr. This is rebased version that reads the LSNs
directly from xlogreader instead of the removed global variables.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2022-03-29 06:07 Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Kyotaro Horiguchi @ 2022-03-29 06:07 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
me> Rebased to the current HEAD.
b64c3bd62e (removal of unused "use Config") conflicted on a TAP
script.
Rebased.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2022-07-06 18:05 Jacob Champion <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
0 siblings, 2 replies; 35+ messages in thread
From: Jacob Champion @ 2022-07-06 18:05 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: Andres Freund <[email protected]>; [email protected]; [email protected]; Michael Paquier <[email protected]>; [email protected]; David Steele <[email protected]>; [email protected]; PostgreSQL Hackers <[email protected]>; [email protected]; Robert Haas <[email protected]>
On Mon, Mar 28, 2022 at 11:07 PM Kyotaro Horiguchi
<[email protected]> wrote:
>
> Rebased.
Unfortunately this will need another rebase over latest.
[CFM hat] Looking through the history here, this has been bumped to
Ready for Committer a few times and then bumped back to Needs Review
after a required rebase. What's the best way for us to provide support
for contributors who get stuck in this loop? Maybe we can be more
aggressive about automated notifications when a RfC patch goes red in
the cfbot?
Thanks,
--Jacob
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2022-07-07 00:04 Michael Paquier <[email protected]>
parent: Jacob Champion <[email protected]>
1 sibling, 0 replies; 35+ messages in thread
From: Michael Paquier @ 2022-07-07 00:04 UTC (permalink / raw)
To: Jacob Champion <[email protected]>; +Cc: Kyotaro Horiguchi <[email protected]>; Andres Freund <[email protected]>; [email protected]; [email protected]; [email protected]; David Steele <[email protected]>; [email protected]; PostgreSQL Hackers <[email protected]>; [email protected]; Robert Haas <[email protected]>
On Wed, Jul 06, 2022 at 11:05:51AM -0700, Jacob Champion wrote:
> [CFM hat] Looking through the history here, this has been bumped to
> Ready for Committer a few times and then bumped back to Needs Review
> after a required rebase. What's the best way for us to provide support
> for contributors who get stuck in this loop? Maybe we can be more
> aggressive about automated notifications when a RfC patch goes red in
> the cfbot?
Having a better integration between the CF bot and the CF app would be
great, IMO. People tend to easily forget about what they send in my
experience, even if they manage a small pool of patches or a larger
one.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2022-07-07 08:32 Kyotaro Horiguchi <[email protected]>
parent: Jacob Champion <[email protected]>
1 sibling, 1 reply; 35+ messages in thread
From: Kyotaro Horiguchi @ 2022-07-07 08:32 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
At Wed, 6 Jul 2022 11:05:51 -0700, Jacob Champion <[email protected]> wrote in
> On Mon, Mar 28, 2022 at 11:07 PM Kyotaro Horiguchi
> <[email protected]> wrote:
> >
> > Rebased.
>
> Unfortunately this will need another rebase over latest.
Thanks! Done.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2022-09-17 04:21 Justin Pryzby <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Justin Pryzby @ 2022-09-17 04:21 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
@cfbot: rebased over adb466150, which did the same thing as one of the
hunks in xlogreader.c.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2022-09-26 07:17 Kyotaro Horiguchi <[email protected]>
parent: Justin Pryzby <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Kyotaro Horiguchi @ 2022-09-26 07:17 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
At Fri, 16 Sep 2022 23:21:50 -0500, Justin Pryzby <[email protected]> wrote in
> @cfbot: rebased over adb466150, which did the same thing as one of the
> hunks in xlogreader.c.
Oops. Thanks! And then this gets a further conflict (param names
harmonization). So further rebased. And removed an extra blank line
you pointed.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2022-10-28 02:37 Justin Pryzby <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
0 siblings, 1 reply; 35+ messages in thread
From: Justin Pryzby @ 2022-10-28 02:37 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
rebased
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2022-11-18 08:25 Kyotaro Horiguchi <[email protected]>
parent: Justin Pryzby <[email protected]>
0 siblings, 2 replies; 35+ messages in thread
From: Kyotaro Horiguchi @ 2022-11-18 08:25 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Just rebased.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2022-11-22 17:20 Andres Freund <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
1 sibling, 0 replies; 35+ messages in thread
From: Andres Freund @ 2022-11-22 17:20 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Hi,
On 2022-11-18 17:25:37 +0900, Kyotaro Horiguchi wrote:
> Just rebased.
Fails with address sanitizer:
https://cirrus-ci.com/task/5632986241564672
Unfortunately one of the failures is in pg_waldump and we don't seem to
capture its output in 011_crash_recovery. So we don't see the nice formattted
output...
[11:07:18.868] #0 0x00007fcf43803ce1 in raise () from /lib/x86_64-linux-gnu/libc.so.6
[11:07:18.912]
[11:07:18.912] Thread 1 (Thread 0x7fcf43662780 (LWP 39124)):
[11:07:18.912] #0 0x00007fcf43803ce1 in raise () from /lib/x86_64-linux-gnu/libc.so.6
[11:07:18.912] No symbol table info available.
[11:07:18.912] #1 0x00007fcf437ed537 in abort () from /lib/x86_64-linux-gnu/libc.so.6
[11:07:18.912] No symbol table info available.
[11:07:18.912] #2 0x00007fcf43b8511b in __sanitizer::Abort () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:155
[11:07:18.912] No locals.
[11:07:18.912] #3 0x00007fcf43b8fce8 in __sanitizer::Die () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:58
[11:07:18.912] No locals.
[11:07:18.912] #4 0x00007fcf43b7244c in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0x7ffd4fde18e6, __in_chrg=<optimized out>) at ../../../../src/libsanitizer/asan/asan_report.cpp:186
[11:07:18.912] buffer_copy = {<__sanitizer::InternalMmapVectorNoCtor<char>> = {data_ = 0x7fcf40350000 '=' <repeats 65 times>, "\n==39124==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x625000002100 at pc 0x55c36c21e315 bp 0x7ffd4fde2550 sp 0x7ffd4fde2"..., capacity_bytes_ = 65536, size_ = <optimized out>}, <No data fields>}
...
[11:07:18.912] #6 0x00007fcf43b72788 in __asan::__asan_report_load1 (addr=<optimized out>) at ../../../../src/libsanitizer/asan/asan_rtl.cpp:117
[11:07:18.912] bp = 140725943412048
[11:07:18.912] pc = <optimized out>
[11:07:18.912] local_stack = 140528180793728
[11:07:18.912] sp = 140725943412040
[11:07:18.912] #7 0x000055c36c21e315 in ValidXLogRecordLength (state=state@entry=0x61a000000680, RecPtr=RecPtr@entry=33655480, record=record@entry=0x625000000bb8) at xlogreader.c:1126
[11:07:18.912] p = <optimized out>
[11:07:18.912] pe = 0x625000002100 ""
[11:07:18.912] #8 0x000055c36c21e3b1 in ValidXLogRecordHeader (state=state@entry=0x61a000000680, RecPtr=RecPtr@entry=33655480, PrevRecPtr=33655104, record=record@entry=0x625000000bb8, randAccess=randAccess@entry=false) at xlogreader.c:1169
[11:07:18.912] No locals.
The most important bit is "AddressSanitizer: heap-buffer-overflow on address 0x6250000\
02100 at pc 0x55c36c21e315 bp 0x7ffd4fde2550 sp 0x7ffd4fde2"
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2022-11-22 22:04 Justin Pryzby <[email protected]>
parent: Kyotaro Horiguchi <[email protected]>
1 sibling, 1 reply; 35+ messages in thread
From: Justin Pryzby @ 2022-11-22 22:04 UTC (permalink / raw)
To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
On Fri, Nov 18, 2022 at 05:25:37PM +0900, Kyotaro Horiguchi wrote:
> + while (*p == 0 && p < pe)
> + p++;
The bug reported by Andres/cfbot/ubsan is here.
Fixed in attached.
I didn't try to patch the test case to output the failing stderr, but
that might be good.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2022-11-30 02:56 Kyotaro Horiguchi <[email protected]>
parent: Justin Pryzby <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Kyotaro Horiguchi @ 2022-11-30 02:56 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
At Tue, 22 Nov 2022 16:04:56 -0600, Justin Pryzby <[email protected]> wrote in
> On Fri, Nov 18, 2022 at 05:25:37PM +0900, Kyotaro Horiguchi wrote:
> > + while (*p == 0 && p < pe)
> > + p++;
>
> The bug reported by Andres/cfbot/ubsan is here.
>
> Fixed in attached.
Ur..ou..
- while (*p == 0 && p < pe)
+ while (p < pe && *p == 0)
It was an off-by-one error. Thanks!
> I didn't try to patch the test case to output the failing stderr, but
> that might be good.
I have made use of Cluster::wait_for_log(), but still find_in_log() is
there since it is used to check if a message that should not be logged
is not logged.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
* [PATCH v6 2/7] Row pattern recognition patch (parse/analysis).
@ 2023-09-12 05:22 Tatsuo Ishii <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Tatsuo Ishii @ 2023-09-12 05:22 UTC (permalink / raw)
---
src/backend/parser/parse_agg.c | 7 +
src/backend/parser/parse_clause.c | 292 +++++++++++++++++++++++++++++-
src/backend/parser/parse_expr.c | 4 +
src/backend/parser/parse_func.c | 3 +
4 files changed, 305 insertions(+), 1 deletion(-)
diff --git a/src/backend/parser/parse_agg.c b/src/backend/parser/parse_agg.c
index 85cd47b7ae..aa7a1cee80 100644
--- a/src/backend/parser/parse_agg.c
+++ b/src/backend/parser/parse_agg.c
@@ -564,6 +564,10 @@ check_agglevels_and_constraints(ParseState *pstate, Node *expr)
errkind = true;
break;
+ case EXPR_KIND_RPR_DEFINE:
+ errkind = true;
+ break;
+
/*
* There is intentionally no default: case here, so that the
* compiler will warn if we add a new ParseExprKind without
@@ -953,6 +957,9 @@ transformWindowFuncCall(ParseState *pstate, WindowFunc *wfunc,
case EXPR_KIND_CYCLE_MARK:
errkind = true;
break;
+ case EXPR_KIND_RPR_DEFINE:
+ errkind = true;
+ break;
/*
* There is intentionally no default: case here, so that the
diff --git a/src/backend/parser/parse_clause.c b/src/backend/parser/parse_clause.c
index 334b9b42bd..60020a7025 100644
--- a/src/backend/parser/parse_clause.c
+++ b/src/backend/parser/parse_clause.c
@@ -100,7 +100,10 @@ static WindowClause *findWindowClause(List *wclist, const char *name);
static Node *transformFrameOffset(ParseState *pstate, int frameOptions,
Oid rangeopfamily, Oid rangeopcintype, Oid *inRangeFunc,
Node *clause);
-
+static void transformRPR(ParseState *pstate, WindowClause *wc, WindowDef *windef, List **targetlist);
+static List *transformDefineClause(ParseState *pstate, WindowClause *wc, WindowDef *windef, List **targetlist);
+static void transformPatternClause(ParseState *pstate, WindowClause *wc, WindowDef *windef);
+static List *transformMeasureClause(ParseState *pstate, WindowClause *wc, WindowDef *windef);
/*
* transformFromClause -
@@ -2950,6 +2953,10 @@ transformWindowDefinitions(ParseState *pstate,
rangeopfamily, rangeopcintype,
&wc->endInRangeFunc,
windef->endOffset);
+
+ /* Process Row Pattern Recognition related clauses */
+ transformRPR(pstate, wc, windef, targetlist);
+
wc->runCondition = NIL;
wc->winref = winref;
@@ -3815,3 +3822,286 @@ transformFrameOffset(ParseState *pstate, int frameOptions,
return node;
}
+
+/*
+ * transformRPR
+ * Process Row Pattern Recognition related clauses
+ */
+static void
+transformRPR(ParseState *pstate, WindowClause *wc, WindowDef *windef, List **targetlist)
+{
+ /*
+ * Window definition exists?
+ */
+ if (windef == NULL)
+ return;
+
+ /*
+ * Row Pattern Common Syntax clause exists?
+ */
+ if (windef->rpCommonSyntax == NULL)
+ return;
+
+ /* Check Frame option. Frame must start at current row */
+ if ((wc->frameOptions & FRAMEOPTION_START_CURRENT_ROW) == 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("FRAME must start at current row when row patttern recognition is used")));
+
+ /* Transform AFTER MACH SKIP TO clause */
+ wc->rpSkipTo = windef->rpCommonSyntax->rpSkipTo;
+
+ /* Transform SEEK or INITIAL clause */
+ wc->initial = windef->rpCommonSyntax->initial;
+
+ /* Transform DEFINE clause into list of TargetEntry's */
+ wc->defineClause = transformDefineClause(pstate, wc, windef, targetlist);
+
+ /* Check PATTERN clause and copy to patternClause */
+ transformPatternClause(pstate, wc, windef);
+
+ /* Transform MEASURE clause */
+ transformMeasureClause(pstate, wc, windef);
+}
+
+/*
+ * transformDefineClause Process DEFINE clause and transform ResTarget into
+ * list of TargetEntry.
+ *
+ * XXX we only support column reference in row pattern definition search
+ * condition, e.g. "price". <row pattern definition variable name>.<column
+ * reference> is not supported, e.g. "A.price".
+ */
+static List *
+transformDefineClause(ParseState *pstate, WindowClause *wc, WindowDef *windef, List **targetlist)
+{
+ /* DEFINE variable name initials */
+ static char *defineVariableInitials = "abcdefghijklmnopqrstuvwxyz";
+
+ ListCell *lc, *l;
+ ResTarget *restarget, *r;
+ List *restargets;
+ char *name;
+ int initialLen;
+ int i;
+
+ /*
+ * If Row Definition Common Syntax exists, DEFINE clause must exist.
+ * (the raw parser should have already checked it.)
+ */
+ Assert(windef->rpCommonSyntax->rpDefs != NULL);
+
+ /*
+ * Check and add "A AS A IS TRUE" if pattern variable is missing in DEFINE
+ * per the SQL standard.
+ */
+ restargets = NIL;
+ foreach(lc, windef->rpCommonSyntax->rpPatterns)
+ {
+ A_Expr *a;
+ bool found = false;
+
+ if (!IsA(lfirst(lc), A_Expr))
+ ereport(ERROR,
+ errmsg("node type is not A_Expr"));
+
+ a = (A_Expr *)lfirst(lc);
+ name = strVal(a->lexpr);
+
+ foreach(l, windef->rpCommonSyntax->rpDefs)
+ {
+ restarget = (ResTarget *)lfirst(l);
+
+ if (!strcmp(restarget->name, name))
+ {
+ found = true;
+ break;
+ }
+ }
+
+ if (!found)
+ {
+ /*
+ * "name" is missing. So create "name AS name IS TRUE" ResTarget
+ * node and add it to the temporary list.
+ */
+ A_Const *n;
+
+ restarget = makeNode(ResTarget);
+ n = makeNode(A_Const);
+ n->val.boolval.type = T_Boolean;
+ n->val.boolval.boolval = true;
+ n->location = -1;
+ restarget->name = pstrdup(name);
+ restarget->indirection = NIL;
+ restarget->val = (Node *)n;
+ restarget->location = -1;
+ restargets = lappend((List *)restargets, restarget);
+ }
+ }
+
+ if (list_length(restargets) >= 1)
+ {
+ /* add missing DEFINEs */
+ windef->rpCommonSyntax->rpDefs = list_concat(windef->rpCommonSyntax->rpDefs,
+ restargets);
+ list_free(restargets);
+ }
+
+ /*
+ * Check for duplicate row pattern definition variables. The standard
+ * requires that no two row pattern definition variable names shall be
+ * equivalent.
+ */
+ restargets = NIL;
+ foreach(lc, windef->rpCommonSyntax->rpDefs)
+ {
+ restarget = (ResTarget *)lfirst(lc);
+ name = restarget->name;
+
+ /*
+ * Add DEFINE expression (Restarget->val) to the targetlist as a
+ * TargetEntry if it does not exist yet. Planner will add the column
+ * ref var node to the outer plan's target list later on. This makes
+ * DEFINE expression could access the outer tuple while evaluating
+ * PATTERN.
+ *
+ * XXX: adding whole expressions of DEFINE to the plan.targetlist is
+ * not so good, because it's not necessary to evalute the expression
+ * in the target list while running the plan. We should extract the
+ * var nodes only then add them to the plan.targetlist.
+ */
+ findTargetlistEntrySQL99(pstate, (Node *)restarget->val, targetlist, EXPR_KIND_RPR_DEFINE);
+
+ /*
+ * Make sure that the row pattern definition search condition is a
+ * boolean expression.
+ */
+ transformWhereClause(pstate, restarget->val,
+ EXPR_KIND_RPR_DEFINE, "DEFINE");
+
+ foreach(l, restargets)
+ {
+ char *n;
+
+ r = (ResTarget *) lfirst(l);
+ n = r->name;
+
+ if (!strcmp(n, name))
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("row pattern definition variable name \"%s\" appears more than once in DEFINE clause",
+ name),
+ parser_errposition(pstate, exprLocation((Node *)r))));
+ }
+ restargets = lappend(restargets, restarget);
+ }
+ list_free(restargets);
+
+ /*
+ * Create list of row pattern DEFINE variable name's initial.
+ * We assign [a-z] to them (up to 26 variable names are allowed).
+ */
+ restargets = NIL;
+ i = 0;
+ initialLen = strlen(defineVariableInitials);
+
+ foreach(lc, windef->rpCommonSyntax->rpDefs)
+ {
+ char initial[2];
+
+ restarget = (ResTarget *)lfirst(lc);
+ name = restarget->name;
+
+ if (i >= initialLen)
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("number of row pattern definition variable names exceeds %d", initialLen),
+ parser_errposition(pstate, exprLocation((Node *)restarget))));
+ }
+ initial[0] = defineVariableInitials[i++];
+ initial[1] = '\0';
+ wc->defineInitial = lappend(wc->defineInitial, makeString(pstrdup(initial)));
+ }
+
+ return transformTargetList(pstate, windef->rpCommonSyntax->rpDefs,
+ EXPR_KIND_RPR_DEFINE);
+}
+
+/*
+ * transformPatternClause
+ * Process PATTERN clause and return PATTERN clause in the raw parse tree
+ */
+static void
+transformPatternClause(ParseState *pstate, WindowClause *wc, WindowDef *windef)
+{
+ ListCell *lc, *l;
+
+ /*
+ * Row Pattern Common Syntax clause exists?
+ */
+ if (windef->rpCommonSyntax == NULL)
+ return;
+
+ /*
+ * Primary row pattern variable names in PATTERN clause must appear in
+ * DEFINE clause as row pattern definition variable names.
+ */
+ wc->patternVariable = NIL;
+ wc->patternRegexp = NIL;
+ foreach(lc, windef->rpCommonSyntax->rpPatterns)
+ {
+ A_Expr *a;
+ char *name;
+ char *regexp;
+ bool found = false;
+
+ if (!IsA(lfirst(lc), A_Expr))
+ ereport(ERROR,
+ errmsg("node type is not A_Expr"));
+
+ a = (A_Expr *)lfirst(lc);
+ name = strVal(a->lexpr);
+
+ foreach(l, windef->rpCommonSyntax->rpDefs)
+ {
+ ResTarget *restarget = (ResTarget *)lfirst(l);
+
+ if (!strcmp(restarget->name, name))
+ {
+ found = true;
+ break;
+ }
+ }
+
+ if (!found)
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("primary row pattern variable name \"%s\" does not appear in DEFINE clause",
+ name),
+ parser_errposition(pstate, exprLocation((Node *)a))));
+ }
+ wc->patternVariable = lappend(wc->patternVariable, makeString(pstrdup(name)));
+ regexp = strVal(lfirst(list_head(a->name)));
+ wc->patternRegexp = lappend(wc->patternRegexp, makeString(pstrdup(regexp)));
+ }
+}
+
+/*
+ * transformMeasureClause
+ * Process MEASURE clause
+ * XXX MEASURE clause is not supported yet
+ */
+static List *
+transformMeasureClause(ParseState *pstate, WindowClause *wc, WindowDef *windef)
+{
+ if (windef->rowPatternMeasures == NIL)
+ return NIL;
+
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("%s","MEASURE clause is not supported yet"),
+ parser_errposition(pstate, exprLocation((Node *)windef->rowPatternMeasures))));
+}
diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
index 64c582c344..18b58ac263 100644
--- a/src/backend/parser/parse_expr.c
+++ b/src/backend/parser/parse_expr.c
@@ -557,6 +557,7 @@ transformColumnRef(ParseState *pstate, ColumnRef *cref)
case EXPR_KIND_COPY_WHERE:
case EXPR_KIND_GENERATED_COLUMN:
case EXPR_KIND_CYCLE_MARK:
+ case EXPR_KIND_RPR_DEFINE:
/* okay */
break;
@@ -1770,6 +1771,7 @@ transformSubLink(ParseState *pstate, SubLink *sublink)
case EXPR_KIND_VALUES:
case EXPR_KIND_VALUES_SINGLE:
case EXPR_KIND_CYCLE_MARK:
+ case EXPR_KIND_RPR_DEFINE:
/* okay */
break;
case EXPR_KIND_CHECK_CONSTRAINT:
@@ -3149,6 +3151,8 @@ ParseExprKindName(ParseExprKind exprKind)
return "GENERATED AS";
case EXPR_KIND_CYCLE_MARK:
return "CYCLE";
+ case EXPR_KIND_RPR_DEFINE:
+ return "DEFINE";
/*
* There is intentionally no default: case here, so that the
diff --git a/src/backend/parser/parse_func.c b/src/backend/parser/parse_func.c
index b3f0b6a137..2ff3699538 100644
--- a/src/backend/parser/parse_func.c
+++ b/src/backend/parser/parse_func.c
@@ -2656,6 +2656,9 @@ check_srf_call_placement(ParseState *pstate, Node *last_srf, int location)
case EXPR_KIND_CYCLE_MARK:
errkind = true;
break;
+ case EXPR_KIND_RPR_DEFINE:
+ errkind = true;
+ break;
/*
* There is intentionally no default: case here, so that the
--
2.25.1
----Next_Part(Tue_Sep_12_15_18_43_2023_359)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="v6-0003-Row-pattern-recognition-patch-planner.patch"
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2024-01-17 05:32 Michael Paquier <[email protected]>
0 siblings, 2 replies; 35+ messages in thread
From: Michael Paquier @ 2024-01-17 05:32 UTC (permalink / raw)
To: Aleksander Alekseev <[email protected]>; +Cc: [email protected]; Kyotaro Horiguchi <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
On Tue, Jan 16, 2024 at 02:46:02PM +0300, Aleksander Alekseev wrote:
>> For now, let me explain the basis for this patch. The fundamental
>> issue is that these warnings that always appear are, in practice, not
>> a problem in almost all cases. Some of those who encounter them for
>> the first time may feel uneasy and reach out with inquiries. On the
>> other hand, those familiar with these warnings tend to ignore them and
>> only pay attention to details when actual issues arise. Therefore, the
>> intention of this patch is to label them as "no issue" unless a
>> problem is blatantly evident, in order to prevent unnecessary concern.
>
> I agree and don't mind affecting the error message per se.
>
> However I see that the actual logic of how WAL is processed is being
> changed. If we do this, at very least it requires thorough thinking. I
> strongly suspect that the proposed code is wrong and/or not safe
> and/or less safe than it is now for the reasons named above.
FWIW, that pretty much sums up my feeling regarding this patch,
because an error, basically any error, would hurt back very badly.
Sure, the error messages we generate now when reaching the end of WAL
can sound scary, and they are (I suspect that's not really the case
for anybody who has history doing support with PostgreSQL because a
bunch of these messages are old enough to vote, but I can understand
that anybody would freak out the first time they see that).
However, per the recent issues we've had in this area, like
cd7f19da3468 but I'm more thinking about 6b18b3fe2c2f and
bae868caf222, I am of the opinion that the header validation, the
empty page case in XLogReaderValidatePageHeader() and the record read
changes are risky enough that I am not convinced that the gains are
worth the risks taken.
The error stack in the WAL reader is complicated enough that making it
more complicated as the patch proposes does not sound like not a good
tradeoff to me to make the reports related to the end of WAL cleaner
for the end-user. I agree that we should do something, but the patch
does not seem like a good step towards this goal. Perhaps somebody
would be more excited about this proposal than I am, of course.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2024-01-22 05:09 Peter Smith <[email protected]>
parent: Michael Paquier <[email protected]>
1 sibling, 1 reply; 35+ messages in thread
From: Peter Smith @ 2024-01-22 05:09 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Aleksander Alekseev <[email protected]>; [email protected]; Kyotaro Horiguchi <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
2024-01 Commitfest.
Hi, This patch has a CF status of "Needs Review" [1], but it seems
there were CFbot test failures last time it was run [2]. Please have a
look and post an updated version if necessary.
======
[1] https://commitfest.postgresql.org/46/2490/
[2] https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/46/2490
Kind Regards,
Peter Smith.
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2024-01-23 04:01 Kyotaro Horiguchi <[email protected]>
parent: Peter Smith <[email protected]>
0 siblings, 0 replies; 35+ messages in thread
From: Kyotaro Horiguchi @ 2024-01-23 04:01 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
At Mon, 22 Jan 2024 16:09:28 +1100, Peter Smith <[email protected]> wrote in
> 2024-01 Commitfest.
>
> Hi, This patch has a CF status of "Needs Review" [1], but it seems
> there were CFbot test failures last time it was run [2]. Please have a
> look and post an updated version if necessary.
>
> ======
> [1] https://commitfest.postgresql.org/46/2490/
> [2] https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/46/2490
Thanks for noticing of that. Will repost a new version.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
* Re: Make mesage at end-of-recovery less scary.
@ 2024-01-23 04:13 Kyotaro Horiguchi <[email protected]>
parent: Michael Paquier <[email protected]>
1 sibling, 0 replies; 35+ messages in thread
From: Kyotaro Horiguchi @ 2024-01-23 04:13 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
At Wed, 17 Jan 2024 14:32:00 +0900, Michael Paquier <[email protected]> wrote in
> On Tue, Jan 16, 2024 at 02:46:02PM +0300, Aleksander Alekseev wrote:
> >> For now, let me explain the basis for this patch. The fundamental
> >> issue is that these warnings that always appear are, in practice, not
> >> a problem in almost all cases. Some of those who encounter them for
> >> the first time may feel uneasy and reach out with inquiries. On the
> >> other hand, those familiar with these warnings tend to ignore them and
> >> only pay attention to details when actual issues arise. Therefore, the
> >> intention of this patch is to label them as "no issue" unless a
> >> problem is blatantly evident, in order to prevent unnecessary concern.
> >
> > I agree and don't mind affecting the error message per se.
> >
> > However I see that the actual logic of how WAL is processed is being
> > changed. If we do this, at very least it requires thorough thinking. I
> > strongly suspect that the proposed code is wrong and/or not safe
> > and/or less safe than it is now for the reasons named above.
>
> FWIW, that pretty much sums up my feeling regarding this patch,
> because an error, basically any error, would hurt back very badly.
> Sure, the error messages we generate now when reaching the end of WAL
> can sound scary, and they are (I suspect that's not really the case
> for anybody who has history doing support with PostgreSQL because a
> bunch of these messages are old enough to vote, but I can understand
> that anybody would freak out the first time they see that).
>
> However, per the recent issues we've had in this area, like
> cd7f19da3468 but I'm more thinking about 6b18b3fe2c2f and
> bae868caf222, I am of the opinion that the header validation, the
> empty page case in XLogReaderValidatePageHeader() and the record read
> changes are risky enough that I am not convinced that the gains are
> worth the risks taken.
>
> The error stack in the WAL reader is complicated enough that making it
> more complicated as the patch proposes does not sound like not a good
> tradeoff to me to make the reports related to the end of WAL cleaner
> for the end-user. I agree that we should do something, but the patch
> does not seem like a good step towards this goal. Perhaps somebody
> would be more excited about this proposal than I am, of course.
Thank you both for the comments. The criticism seems valid. The
approach to identifying the end-of-WAL state in this patch is quite
heuristic, and its validity or safety can certainly be contested. On
the other hand, if we seek perfection in this area of judgment, we may
need to have the WAL format itself more robust. In any case, since the
majority of the feedback on this patch seems to be negative, I am
going to withdraw it if no supportive opinions emerge during this
commit-fest.
The attached patch addresses the errors reported by CF-bot.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 35+ messages in thread
end of thread, other threads:[~2024-01-23 04:13 UTC | newest]
Thread overview: 35+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-02-28 07:01 Make mesage at end-of-recovery less scary. Kyotaro Horiguchi <[email protected]>
2020-02-28 07:33 ` Michael Paquier <[email protected]>
2020-02-28 08:28 ` Kyotaro Horiguchi <[email protected]>
2020-03-05 07:06 ` Kyotaro Horiguchi <[email protected]>
2020-03-23 09:37 ` Peter Eisentraut <[email protected]>
2020-03-23 17:43 ` Ashwin Agrawal <[email protected]>
2020-03-23 19:49 ` Andres Freund <[email protected]>
2020-03-23 19:47 ` Andres Freund <[email protected]>
2020-03-24 01:52 ` Kyotaro Horiguchi <[email protected]>
2020-03-25 12:53 ` Peter Eisentraut <[email protected]>
2020-03-26 16:40 ` Robert Haas <[email protected]>
2020-03-28 02:25 ` James Coleman <[email protected]>
2021-03-03 16:14 ` David Steele <[email protected]>
2021-03-04 06:50 ` Kyotaro Horiguchi <[email protected]>
2021-10-22 17:54 ` Bossart, Nathan <[email protected]>
2021-11-08 05:59 ` Kyotaro Horiguchi <[email protected]>
2021-11-09 00:53 ` Michael Paquier <[email protected]>
2021-11-09 07:27 ` Kyotaro Horiguchi <[email protected]>
2021-12-08 07:01 ` Kyotaro Horiguchi <[email protected]>
2022-03-29 06:07 Re: Make mesage at end-of-recovery less scary. Kyotaro Horiguchi <[email protected]>
2022-07-06 18:05 ` Jacob Champion <[email protected]>
2022-07-07 00:04 ` Michael Paquier <[email protected]>
2022-07-07 08:32 ` Kyotaro Horiguchi <[email protected]>
2022-09-17 04:21 ` Justin Pryzby <[email protected]>
2022-09-26 07:17 ` Kyotaro Horiguchi <[email protected]>
2022-10-28 02:37 ` Justin Pryzby <[email protected]>
2022-11-18 08:25 ` Kyotaro Horiguchi <[email protected]>
2022-11-22 17:20 ` Andres Freund <[email protected]>
2022-11-22 22:04 ` Justin Pryzby <[email protected]>
2022-11-30 02:56 ` Kyotaro Horiguchi <[email protected]>
2023-09-12 05:22 [PATCH v6 2/7] Row pattern recognition patch (parse/analysis). Tatsuo Ishii <[email protected]>
2024-01-17 05:32 Re: Make mesage at end-of-recovery less scary. Michael Paquier <[email protected]>
2024-01-22 05:09 ` Peter Smith <[email protected]>
2024-01-23 04:01 ` Kyotaro Horiguchi <[email protected]>
2024-01-23 04:13 ` Kyotaro Horiguchi <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox