From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Timothy Garnett <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-08 12:32:20 |
Message-ID: | 484646479.1823884.1428496340597.JavaMail.yahoo@mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Timothy Garnett <tgarnett(at)panjiva(dot)com> wrote:
>>> - why didn't vacuum_db -a -F free up more members files?
>>
>> Are you sure that while the problem was developing the primary
>> cluster didn't have any long-running transactions (including
>> those left "idle in transaction" or prepared transactions)? Was
>> there a checkpoint following the vacuumdb -a -F run?
>
> The vacuum_db was run after we recovered from backup (which
> involved restarting the server) so at the time the vacuum_db
> started there were no open transactions. There have have been
> checkpoints since the vacuum_db finished as well.
>
> In the lead up to the problem there wouldn't have been any
> transactions open more then a couple of hours (the oldest members
> file was over 6 months old).
Thanks; that helps narrow where we need to look for the bug. Just
to be sure, what are the results of?:
SHOW max_prepared_transactions;
If that is non-zero, do you have any monitoring for rows in the
pg_prepared_xacts view with a "prepared" value older than some
reasonable threshold?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Timothy Garnett | 2015-04-08 13:25:59 | Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated) |
Previous Message | Michael Paquier | 2015-04-08 04:27:08 | Re: PQexec() hangs on OOM |