From: | Alexey Klyukin <alexk(at)hintbits(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Could not open file pg_multixact/offsets/ ERROR on 9.3.4 |
Date: | 2014-06-05 16:34:24 |
Message-ID: | CAAS3ty+2ynCyf_YmRn6WuqSF8EmJMDypAkc7uD_EXTZJ7usOSg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 4, 2014 at 5:10 PM, Andres Freund <andres(at)2ndquadrant(dot)com>
wrote:
> Looks like you're hitting the issue described in
>
> http://archives.postgresql.org/message-id/20140530121631.GE25431%40alap3.anarazel.de
Aha, so the problem looks like this:
- all multixact contents was purged (9.2 to 9.3 incompatibility)
- the only offset was the 0000 file created by initidb during bootstrap
- truncation code in vacuum assumed the page related to multixact it tried
to truncate actually exists
- the assumption was based on the fact that there exists a page earlier
than the one it tried to truncate
- due to the wrong assumption, there was an attempt to truncate a
non-existing page, resulting in the error.
Now that makes sense, thank you very much. Vacuum runs w/o issues once I
removed that 0000 file.
I think it should be safe to recommend removing the 0000 file for everyone
with the same problem.
The 2 cases where 0000 file is actually used are:
- when the are no more then 2 pages of offsets (0000 and 0001) since the
server creation
- when the multixacts wrapped around and 0000 is not the first page.
I think in both cases there will be no gaps in segments in offsets,
so the problem won't be there in the first place.
Cheers,
--
Alexey Klyukin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-06-05 17:39:57 | Re: performance regression in 9.2/9.3 |
Previous Message | Alvaro Herrera | 2014-06-05 16:33:28 | Re: slotname vs slot_name |