Re: pg_upgrade - link mode and transaction-wraparound data loss - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade - link mode and transaction-wraparound data loss
Date
Msg-id 201005181956.o4IJumw18267@momjian.us
Whole thread Raw
In response to Re: pg_upgrade - link mode and transaction-wraparound data loss  (Jesper Krogh <jesper@krogh.cc>)
Responses Re: pg_upgrade - link mode and transaction-wraparound data loss
List pgsql-hackers
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.

> > I am wondering if you set datallowconn for template0 to 'true'.
> 
>  From this database, I cannot give any more results, I ran some other
> queries and then restarted postgres, subsequently it seemed
> totally broken. I'm in the process of running the test over again, but
> it'll take a while before data is in.  I'll report back.

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.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com


pgsql-hackers by date:

Previous
From: Jesper Krogh
Date:
Subject: Re: pg_upgrade - link mode and transaction-wraparound data loss
Next
From: Heikki Linnakangas
Date:
Subject: Re: Synchronous replication patch built on SR