On Mon, Jun 1, 2015 at 8:53 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> What about prepared transactions? They can lock rows FOR SHARE that
> survive server restarts.
And they can make update chains that are still uncommitted after a restart.
I think we should think separately about what information we want to
store in the tuple ideally and only then worry about how to encode it
concisely as an optimization exercise. If you just grow every tuple by
64-bits would this scheme be trivial? Perhaps it would be worth
implementing that way first and then worrying about how to recuperate
that space later?
--
greg
