On Wed, 18 Dec 2019 at 18:37, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@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. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Solutions for the Enterprise
