Re: Read Uncommitted

On Wed, 18 Dec 2019 at 18:37, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Simon Riggs <simon(at)2ndquadrant(dot)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