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
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 |