On 6 June 2017 at 12:38, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote:
> 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.

Tom's point is, I think, that we'll want to stay pg_upgrade
compatible. So when we see a pg10 tuple and want to add a new page
with a new page header that has an epoch, but the whole page is full
so there isn't 32 bits left to move tuples "down" the page, what do we

 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to