| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Thom Brown <thom(at)linux(dot)com> |
| Cc: | Nick Ivanov <nick(dot)ivanov(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: incremental backup issue |
| Date: | 2026-07-13 22:28:14 |
| Message-ID: | CA+Tgmob8w+YvVCPr2_P3VyLYTYpVADyp6ubiADYRdf3viONKqg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 13, 2026 at 6:07 PM Thom Brown <thom(at)linux(dot)com> wrote:
> Ha, yes, this is certainly a clear example of the confidence AI puts
> in its own conclusions not being indicative of reliability.
Yep. And it's an odd oversight, too, since apportioning blame between
SummarizeWAL and its caller seems to be the whole deal here, and the
comments are how you figure out whose fault it is (at least, if they
say anything useful).
> So really, this doesn't sound like this is solved, not that these
> changes aren't still necessary.
I assume it's likely that Fabrice ended up with a not-totally-valid
WAL file in the archive after some series of manual steps and couldn't
quite remember what had been done well enough to provide an exact
reproducer. That seems like a completely reasonable thing to happen to
somebody. Now it's also possible that there is some as-yet-unknown way
for this to happen without manual fudging, but unless somebody can
figure out what that is exactly, it's hard to say what we ought to do
about it.
> > I attach a patch. I don't think we need anything like the 0002 in your
> > proposal from claude. The read horizon used by the WAL summarizer
> > *has* to be valid; if we can't achieve that, we're doomed.
>
> Nick, you said that you saw something "similar" (suggesting that it's
> not identical), but you didn't explain what that was. Is there
> potentially a separate bug that needs reporting?
See the "walsummarizer can get stuck when switching timelines" thread.
That case occurs when there's a timeline switch and the file from the
old timeline doesn't make it into the archive at all. This case occurs
where there's a timeline switch and a corrupted file from the old
timeline makes it into the archive. It's possible to reproduce that
case without any manual steps; see the included test case on that
thread. As I say, I can believe that there could be a way to reproduce
this case without manual steps too, but I don't know what it is.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matheus Alcantara | 2026-07-13 22:51:16 | Re: hashjoins vs. Bloom filters (yet again) |
| Previous Message | Andreas Karlsson | 2026-07-13 22:25:42 | Re: Grab bag of smaller OpenSSL fixups |