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