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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
