On Tue, Jul 14, 2020 at 3:26 AM Tom Lane <tgl@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