Re: Make mesage at end-of-recovery less scary.

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, vignesh21(at)gmail(dot)com, stark(dot)cfm(at)gmail(dot)com, alvherre(at)alvh(dot)no-ip(dot)org, pryzby(at)telsasoft(dot)com, andres(at)anarazel(dot)de, ashu(dot)coek88(at)gmail(dot)com, pashkin(dot)elfe(at)gmail(dot)com, michael(at)paquier(dot)xyz, bossartn(at)amazon(dot)com, david(at)pgmasters(dot)net, peter(dot)eisentraut(at)2ndquadrant(dot)com, jtc331(at)gmail(dot)com, robertmhaas(at)gmail(dot)com
Subject: Re: Make mesage at end-of-recovery less scary.
Date: 2024-01-16 11:46:02
Message-ID: CAJ7c6TPnb2PUvV1xU8mUhos+A-8zB4r+KzTCxfyKvDS1if7BQA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

> > If I understand correctly, if somehow several FS blocks end up being
> > zeroed (due to OS bug, bit rot, restoring from a corrupted for
> > whatever reason backup, hardware failures, ...) there is non-zero
> > chance that PG will interpret this as a normal situation. To my
> > knowledge this is not what we typically do - typically PG would report
> > an error and ask a human to figure out what happened. Of course the
> > possibility of such a scenario is small, but I don't think that as
> > DBMS developers we can ignore it.
>
> 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.

--
Best regards,
Aleksander Alekseev

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message feichanghong 2024-01-16 11:51:47 "ERROR: could not open relation with OID 16391" error was encountered when reindexing
Previous Message Anton A. Melnikov 2024-01-16 11:23:56 Re: ResourceOwner refactoring