Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby
От | Andres Freund |
---|---|
Тема | Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby |
Дата | |
Msg-id | 20131209162849.GB9519@awork2.anarazel.de обсуждение исходный текст |
Ответ на | BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby (petr@petrovich.kiev.ua) |
Ответы |
Re: BUG #8673: Could not open file "pg_multixact/members/xxxx"
on slave during hot_standby
|
Список | pgsql-bugs |
On 2013-12-09 17:49:34 +0200, Serge Negodyuck wrote: > Latest checkpoint's NextXID: 0/90546484 > Latest checkpoint's NextOID: 6079185 > Latest checkpoint's NextMultiXactId: 42049949 > Latest checkpoint's NextMultiOffset: 55384024 > Latest checkpoint's oldestXID: 710 > Latest checkpoint's oldestXID's DB: 1 > Latest checkpoint's oldestActiveXID: 90546475 > Latest checkpoint's oldestMultiXid: 1 > Latest checkpoint's oldestMulti's DB: 1 So, the oldest multi is 1, thus the truncation code wouldn't have been able to remove any. So I think this really is an independent problem from the truncation patch. But a problem nonetheless. > > Could you also provide ls -l pg_multixact/ on both primary and standby? > > Did you mean pg_multixact/members/ ? From both members, and offset. I'd be great if you could attach a ls -lR of pg_multixact/. > I't not possible on slave right now. Since I had to re-sync these > files from master. May be that was not a good idea but it helped. > > On master there are files from 0000 to 14078 > > On slave there were absent files from A1xx to FFFF > They were the oldest ones. (October, November) Hm. Were files from before A1xx, I am not sure how to parse your answer. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-bugs по дате отправления: