Re: emergency outage requiring database restart

On 10/22/16 12:38 PM, Tom Lane wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
>> > On 10/21/16 7:43 PM, Tom Lane wrote:
>>> >> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
>>> >> RENAME TABLE.
>> > 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
> crash.)

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