Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)?
От | Ashutosh Bapat |
---|---|
Тема | Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)? |
Дата | |
Msg-id | CAFjFpRdobHngmRsvhLmxA-wnvUyrFFMQeCVTM2MnC2qDNP=vsQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)? (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Challenges preventing us moving to 64 bit transaction id (XID)?
Re: [HACKERS] Challenges preventing us moving to 64 bit transactionid (XID)? |
Список | pgsql-hackers |
On Tue, Jun 6, 2017 at 9:48 AM, Craig Ringer <craig@2ndquadrant.com> wrote: > On 6 June 2017 at 12:13, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote: > >> What happens when the epoch is so low that the rest of the XID does >> not fit in 32bits of tuple header? Or such a case should never arise? > > 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? May be not, since such tuples will be anyway visible to any concurrent scans and updating xmin/xmax doesn't change the visibility. But we might have to prevent multiple updates to the xmin/xmax because of concurrent updates on the same page. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: