From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "tgarnett(at)panjiva(dot)com" <tgarnett(at)panjiva(dot)com> |
Cc: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
Date: | 2015-04-21 21:16:01 |
Message-ID: | 682806730.1514266.1429650961503.JavaMail.yahoo@mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> Here's a patch. I have tested locally and it closes the issue
> for me. If those affected can confirm that it stops the file
> removal from happening, I'd appreciate it.
Based on initial testing, it seems to stop file removal from
happening rather too well. Before applying the patch I ran a test
test that generated files 0000 to 1185D in the members directory.
Even setting vacuum_multixact_freeze_min_age and
vacuum_multixact_freeze_table_age very low, none of the members
files would go away with VACUUM (with and without FREEZE) followed
by CHECKPOINT. After applying the patch and starting with a fresh
initdb, with very low settings of the vacuum_multixact_* GUCs I get
the new error almost immediately, while the only file in the
members subdirectory is 0000 and it is 8kB in size.
I think the calculations might be wrong, but I'm not sure what does
make sense.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-04-22 00:56:48 | contrib/start-scripts/linux failing on RHEL 6 with ~9.3 because of missing oom_score_adj |
Previous Message | David G. Johnston | 2015-04-21 15:28:20 | Re: BUG #13112: Catastrophic performance degradation without DISTINCT ON statement |