Simon Riggs <simon@2ndquadrant.com> writes: > So this is the same discussion as elsewhere about potentially aborted > transactions... > AFAIK, the worst that happens in that case is that the reading transaction > will end with an ERROR, similar to a serializable error.
No, the worst case is transactions trying to read invalid data, resulting in either crashes or exploitable security breaches (in the usual vein of what can go wrong if you can get the C code to follow an invalid pointer).
Yes, but we're not following any pointers as a result of this. The output is just rows.
This seems possible, for example, if you can get a transaction to read uncommitted data that was written according to some other rowtype than what the reading transaction thinks the table rowtype is. Casting my eyes through AlterTableGetLockLevel(), it looks like all the easy ways to break it like that are safe (for now) because they require AccessExclusiveLock. But I am quite afraid that we'd introduce security holes by future reductions of required lock levels --- or else that this feature would be the sole reason why we couldn't reduce the lock level for some DDL operation. I'm doubtful that its use-case is worth that.
I think we can limit it to Read Only transactions without any limitation on the proposed use cases.
But I'll think some more about that, just in case.
> And that won't happen in the use cases I've explicitly described this as > being useful for, which is where the writing transactions have completed > executing.
My concerns, at least, are not about whether this has any interesting use-cases. They're about whether the feature can be abused to cause security problems. I think the odds are fair that that'd be true even today, and higher that it'd become true sometime in the future.
I share your concerns. We have no need or reason to make a quick decision on this patch.
I submit this patch only as a useful tool for recovering data.