Peter Eisentraut <pe...@eisentraut.org> writes: > The problem is, we don't really have any end-to-end coverage of
> dump > restore > dump again > compare the two dumps > with a database with lots of interesting objects in it. I'm very much against adding another full run of the core regression tests to support this. But beyond the problem of not bloating the check-world test runtime, there is the question of what this would actually buy us. I doubt that it is worth very much, because it would not detect bugs-of-omission in pg_dump. As I remarked in the other thread, if pg_dump is blind to the existence of some feature or field, testing that the dumps compare equal will fail to reveal that it didn't restore that property. I'm not sure what we could do about that. One could imagine writing some test infrastructure that dumps out the contents of the system catalogs directly, and comparing that instead of pg_dump output. But that'd be a lot of infrastructure to write and maintain ... and it's not real clear why it wouldn't *also* suffer from I-forgot-to-add-this hazards. On balance, I think there are good reasons that we've not added such a test, and I don't believe those tradeoffs have changed. regards, tom lane