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

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: pg_upgrade - link mode and transaction-wraparound data loss
Дата
Msg-id 201005182116.o4ILGOQ09352@momjian.us
обсуждение исходный текст
Ответ на Re: pg_upgrade - link mode and transaction-wraparound data loss  (Jesper Krogh <jesper@krogh.cc>)
Ответы Re: pg_upgrade - link mode and transaction-wraparound data loss  (Bruce Momjian <bruce@momjian.us>)
Список 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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Caleb Welton
Дата:
Сообщение: Re: Bug with ordering aggregates?
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Keepalive for max_standby_delay