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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Jesper Krogh <jesper(at)krogh(dot)cc>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_upgrade - link mode and transaction-wraparound data loss
Date: 2010-05-18 21:16:24
Message-ID: 201005182116.o4ILGOQ09352@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jesper Krogh wrote:
> 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)

I am on chat with Alvaro now and it seems we do somehow connect to
template0 for transaction id wraparound. I think Alvaro will post
shortly on this.

> > 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.

Thanks, but I think the entire problem might be this template0 xid issue
that Alvaro and I are researching. I can now see how invalid template0
xids could cause the instability you saw in the new database. Odd no
one has seen this bug before.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-05-18 21:17:46 Re: Keepalive for max_standby_delay
Previous Message Alex Hunsaker 2010-05-18 21:12:52 Re: BYTEA / DBD::Pg change in 9.0 beta