On Tue, Jun 6, 2017 at 06:00:54PM +0800, Craig Ringer wrote: > 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: > >> 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 > do?
I guess I am missing something. If you see an old page version number, you know none of the tuples are from running transactions so you can just freeze them all, after consulting the pg_clog. What am I missing? If the page is full, why are you trying to add to the page? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
