On Mon, Jun 1, 2015 at 8:53 PM, Thomas Munro <thomas.mu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
