On Mon, Jun 1, 2015 at 8:53 PM, Thomas Munro <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
