Re: BUG #15142: ERROR: MultiXactId nnnnn has not been created yet --apparent wraparound in v9.5
От | molofeev |
---|---|
Тема | Re: BUG #15142: ERROR: MultiXactId nnnnn has not been created yet --apparent wraparound in v9.5 |
Дата | |
Msg-id | 9fc8fe69-08d3-a945-0483-7c532d78c25e@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #15142: ERROR: MultiXactId nnnnn has not been created yet --apparent wraparound in v9.5 (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: BUG #15142: ERROR: MultiXactId nnnnn has not been created yet -- apparent wraparound in v9.5
|
Список | pgsql-bugs |
Query: select * from TABLE_NAME where ctid between '(0,1)'::tid and '(1,1)'::tid; return ERROR: MultiXactId 1048586 has not been created yet -- apparent wraparound Tuple #161 has ctid = (3220145, 81) On 04/04/2018 12:22 PM, Tomas Vondra wrote: > On 04/04/2018 10:20 AM, molofeev wrote: >> Any ideas? >> >> >> On 04/03/2018 04:36 PM, molofeev wrote: >>> The last query that working is - select * from TABLE_NAME limit 1 >>> offset 160; >>> >>> the next query >>> >>> select * from TABLE_NAME limit 1 offset 162; >>> >>> return - ERROR: MultiXactId 1048586 has not been created yet -- >>> apparent wraparound >>> SQL state: XX000 >>> > Well, as Alvaro mentioned, we need to see the page that contains the > record with that multixactid. You now know which table it is, and you > know it's tuple #162. We still don't know which page is it exactly, but > you can determine that by using CTID: > > select * from TABLE_NAME where ctid between '(13,1)'::tid > and '(14,0)'::tid; > > You'll need to start on page 0 and increase it until you get the error > again. This will scan the whole table, though. > > Then you know which page has the broken data, and you can inspect it > using pageinspect - extract it using raw_page, inspect it using various > functions in that extension. I don't know how sensitive the data in that > table is, but perhaps you may share the 8kB page. > > FWIW this seems to be some sort of data corruption, where the XID got > overwritten by a bogus value in some way. The bigger question is how > many other such cases are there. > > regards >
В списке pgsql-bugs по дате отправления: