On 10/22/16 12:38 PM, Tom Lane wrote:
Jim Nasby <jim.na...@bluetreble.com> writes:
> On 10/21/16 7:43 PM, Tom Lane wrote:
>> Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
>>> Agreed.  The problem is how to install it without breaking pg_upgrade.
> It can't look up relation names?
It can't shove 64 bytes into a page that has < 64 bytes free space.

Yeah, that would need to be a special case, but unless the page pointers are horked you'd be able to tell if there was a name in there.

>> Well, that's the first problem.  The second problem is how to cope with
> If the name was only encoded in the first block of the relation I'm not
> sure how bad this would be; are there any facilities to change the name
> back on a rollback?
No.  How would that work in crash situations?  (And keep in mind that the

Well, if FPI's were enabled you'd get the old page back. Even without that recovery could remember rename records it's seen that didn't commit.

argument for this hinges entirely on its being 100% trustworthy after a

I don't think this needs to be 100% reliable to be useful, especially if we went with Andreas suggestion to store both the old and new name (and storing the OID as well isn't a bad idea). If you're ever at the point of looking at this info you're already in deep trouble and should already be taking everything with a grain of salt anyway.
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

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

Reply via email to