On Tue, Jul 14, 2020 at 3:26 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > I think you're attacking a straw man. I'm well aware of how open source > works, thanks. What I'm saying is that contrib is mostly seen to be > reasonably harmless stuff. Sure, you can overwrite data you didn't want > to with adminpack's pg_file_write. But that's the price of having such a > capability at all, and in general it's not hard for users to understand > both the uses and risks of that function. That statement does not apply > to the functions being proposed here. It doesn't seem like they could > possibly be safe to use without very specific expert advice --- and even > then, we're talking rather small values of "safe".
Would it be possible to make them safe(r)? For instance, truncate only, don't freeze; only tuples whose visibility information is corrupted; and only in non-catalog tables. What exactly is the risk in that case? Foreign keys might not be satisfied, which might make it impossible to restore a dump, but is that worse than what a DBA can do anyway? I would think that it is not and would leave the database in a state DBAs are much better equipped to deal with. Or would it be possible to create a table like the original table (minus any constraints) and copy all tuples with corrupted visibility there before truncating to a dead line pointer? Jochem
