Date: Fri, 10 Oct 2014 07:37:01 -0700 (PDT)
From: jim_yates <pg@wg5jim.net>
To: pgsql-sql@postgresql.org
Message-ID: <1412951821680-5822573.post@n5.nabble.com>
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>
Subject: Re: could not access status of transaction pg_multixact issue
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-sql-owner@postgresql.org

Alvaro Herrera-9 wrote
> jim_yates wrote:
>=20
>> Then I'm really confused.=20=20
>> 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.=20=20
>>=20
>> And the NextMultiXactId from pg_controldump is  303464.
>>=20
>> So if I use the min value from pg_class then I have some other issue.=20=
=20
>>=20
>> Where should I get the new pg_database value from?
>=20
> I'm deep in another issue which I don't want to page out right now, but
> try vacuuming the tables that have relminmxid=3D1 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.
>=20
> --=20
> =C3=81lvaro 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=3D'1' and relkind=
=3D'r'
using pg_class as the source.
I still couldn't vacuum or select the original table with the issue.=20
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-tp5822248p5822573.html
Sent from the PostgreSQL - sql mailing list archive at Nabble.com.


--=20
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql