On Tue, Jun 6, 2017 at 10:00 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> writes: >> On Tue, Jun 6, 2017 at 9:48 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: >>> Storing an epoch implies that rows can't have (xmin,xmax) different by >>> more than one epoch. So if you're updating/deleting an extremely old >>> tuple you'll presumably have to set xmin to FrozenTransactionId if it >>> isn't already, so you can set a new epoch and xmax. > >> If the page has multiple such tuples, updating one tuple will mean >> updating headers of other tuples as well? This means that those tuples >> need to be locked for concurrent scans? > > Locks for tuple header updates are taken at page level anyway, so in > principle you could run around and freeze other tuples on the page > anytime you had to change the page's high-order-XID value. Holding > the lock for long enough to do that is slightly annoying, but it > should happen so seldom as to not represent a real performance problem. > > In my mind the harder problem is where to find another 32 bits for the > new page header field. You could convert the header format on-the-fly > if there's free space in the page, but what if there isn't?
I guess, we will have to reserve 32 bits in the header. That's much better than increasing tuple header by 32 bits. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
