Re: pg_upgrade - link mode and transaction-wraparound data loss

On 2010-05-18 21:56, Bruce Momjian wrote:
> Jesper Krogh wrote:
>    
>> On 2010-05-18 20:52, Bruce Momjian wrote:
>>      
>>> This line above looks very odd because I didn't think the template0
>>> datfrozenxid could be advanced.  Can I see the output of this query:
>>>
>>>     SELECT datname, datfrozenxid, datallowconn FROM pg_database;
>>>
>>>
>>>        
>> Only from the "old" database:
>> data=# SELECT datname, datfrozenxid, datallowconn FROM pg_database;
>>     datname  | datfrozenxid | datallowconn
>> -----------+--------------+--------------
>>    template0 |   2073823552 | f
>>    postgres  |   2023820521 | t
>>    data      |   2023782337 | t
>>    jk        |   2023822188 | t
>>    template1 |   2073823552 | t
>>    workqueue |   2023822188 | t
>> (6 rows)
>>      
> OK, datallowconn = false is right for template0, but I am still confused
> how it got set to that high value.
>    

This is the "production system". I have absolutely no indications that
anything should be wrong in there. It has run rock-solid since it got
migrated (dump/restore) to 8.4 for about 7 months now. So I am a bit
scared about you telling that it seems wrong. (but that cannot be
attributed to pg_upgrade)

> OK, thanks.  This does seem odd.  Frankly, having template0's
> datfrozenxid be wrong would not cause any kind of instability because
> template0 is used only by pg_dump, so I am wondering if something else
> is seriously wrong.
>    
I also think that something was seriously wrong with the pg_upgrade'd
version. I'll try to reproduce and be a bit more carefull in tracking 
the steps
this time.

-- 
Jesper