agora inbox for pgsql-sql@postgresql.org
help / color / mirror / Atom feedFrom: jim_yates <pg@wg5jim.net>
To: pgsql-sql@postgresql.org
Subject: Re: could not access status of transaction pg_multixact issue
Date: Fri, 10 Oct 2014 07:37:01 -0700 (PDT)
Message-ID: <1412951821680-5822573.post@n5.nabble.com> (raw)
In-Reply-To: <20141009203637.GH7043@eldon.alvh.no-ip.org>
References: <20141008185538.GY7043@eldon.alvh.no-ip.org>
<1412797415000-5822268.post@n5.nabble.com>
<20141008205416.GZ7043@eldon.alvh.no-ip.org>
<1412863620263-5822376.post@n5.nabble.com>
<5436A34C.8090306@aklaver.com>
<20141009151229.GD7043@eldon.alvh.no-ip.org>
<1412874160409-5822399.post@n5.nabble.com>
<20141009180022.GE7043@eldon.alvh.no-ip.org>
<1412885826355-5822449.post@n5.nabble.com>
<20141009203637.GH7043@eldon.alvh.no-ip.org>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-sql>
Alvaro Herrera-9 wrote
> jim_yates wrote:
>
>> Then I'm really confused.
>> The minimum relminmxid for all the rows in pg_class that have relminmxid
>> greater then zero is 1.
>> That's the current value of datminmxid in pg_database.
>>
>> And the NextMultiXactId from pg_controldump is 303464.
>>
>> So if I use the min value from pg_class then I have some other issue.
>>
>> Where should I get the new pg_database value from?
>
> I'm deep in another issue which I don't want to page out right now, but
> try vacuuming the tables that have relminmxid=1 with low values set for
> vacuum_multixact_freeze_table_age and vacuum_multixact_freeze_min_age,
> say 100000. (I think 65536 ought to get you beyond segment
> pg_multixact/offset/0000, and then that file would be removed.) Since
> any multixact values below the point at which pg_upgrade ran should be
> marked "no longer running" through hint bits, there would be no
> pg_multixact lookups anyway and thus the vacuuming should complete with
> no errors.
>
> --
> Álvaro Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
I set vacuum_multixact_freeze_table_age and vacuum_multixact_freeze_min_age
to 100,000 and vacuumed all the tables with a relminmxid='1' and relkind='r'
using pg_class as the source.
I still couldn't vacuum or select the original table with the issue.
I did solve the problem by dropping the table and restoring from my standby
server.
Is there else anything I need to do to prevent being bitten by this bug
again?
I still have a value of 1 for datminmxid in pg_database, and the 0000 file
is still in pg_multixact/members and offsets.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/could-not-access-status-of-transaction-pg-multixact-issue-tp...
Sent from the PostgreSQL - sql mailing list archive at Nabble.com.
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
view thread (16+ messages) latest in thread
Message-ID: <1412951821680-5822573.post@n5.nabble.com>
Permalink: ../1412951821680-5822573.post@n5.nabble.com/
Also on: postgresql.org/message-id/1412951821680-5822573.post@n5.nabble.com
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: pg@wg5jim.net
Subject: Re: could not access status of transaction pg_multixact issue
In-Reply-To: <1412951821680-5822573.post@n5.nabble.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox