| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: scary patch contest |
| Date: | 2026-08-26 15:13:16 |
| Message-ID: | ao8CjOEo_NWevKxb@momjian.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Aug 26, 2026 at 10:29:36AM -0400, Andres Freund wrote:
> > 3. Online data checksums (f19c0eccae9, Daniel Gustafsson and Magnus
> > Hagander): ~25 substantive fixes, mostly state-machine holes — invalid
> > transitions in checkpoints and promotion, initial state missing from
> > the control file, basebackup false checksum failures, wrong WAL for
> > unlogged relations. A corruption-detection feature producing false
> > positives is exactly the wrong failure mode.
>
> I'm not *too* concerned about this one. In contrast to most of the other
> features here it's a super user only feature that you're not going to use
> continuously. If it turns out to be too problematic, disabling it is a few
> lines.
I was thinking that too. Would the worst case be that people will have
to disable and re-enable checksums again. Is that something we could
actually give people a workflow for?
Seeing anything removed from the major release note will feel painful,
but perhaps necessary.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-08-26 15:17:55 | Re: Internal error codes triggered by regression tests and user queries, take 2 |
| Previous Message | Henson Choi | 2026-08-26 15:11:54 | Re: Row pattern recognition |