On 8/21/24 14:58, Robert Haas wrote:
> ...
>
> All we're doing here is taking an incremental backup of 1-table
> database that had 1 row at the time of the full backup and has had 1
> more row inserted since then. On my system, the last time I ran this
> regression test, this step completed in 410ms. It shouldn't be
> expensive. So I'm inclined to chalk this up to the machine not having
> enough resources. The only thing that I don't really understand is why
> this particular test would fail vs. anything else. We have a bunch of
> tests that take backups. A possibly important difference here is that
> this one is an incremental backup, so it would need to read WAL
> summary files from the beginning of the full backup to the beginning
> of the current backup and combine them into one super-summary that it
> could then use to decide what to include in the incremental backup.
> However, since this is an artificial example with just 1 insert
> between the full and the incremental, it's hard to imagine that being
> expensive, unless there's some low-probability bug that makes it go
> into an infinite loop or chew up a million CPU cycles or something.
> That's not impossible, but given the discussion between you and Tomas,
> I'm kinda hoping it was just a hardware issue.
>
> Barring objections or other similar trouble reports, I think we should
> just close out this open item.
>
+1 to just close it
The animal is running FreeBSD on rpi4, and used to be running from a
flash disk. Seems FreeBSD has some trouble with that, which likely
contributed to the failures (a bit weird it affected just this test).
Moving to a better storage (SATA SSD over USB) improved the situation
quite a bit. It's a bit too early to say for sure, ofc. But I don't
think the test itself is broken.
regards
--
Tomas Vondra
