Re: BUG #11264: Auto vacuum wraparound job blocking everything

Yes, it was upgraded a month ago using postgresql 9.3.4 binaries. It was
just patched up last week with 9.3.5.

I checked all the other servers which we upgraded using postgres 9.3.5
binaries, oldestMultiXid is other than 1 and it seems to be have picked
the right number. But the server in question was upgraded using postgres
9.3.4 binaries. This sounds suspicious. Could it be pg_upgrade in 9.3.4 is
buggy.

How do we fix the current issue with this one server? Is there an easy fix?
Thanks.
Dinesh

On 8/27/14, 9:45 AM, "Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com> wrote:

>Dinesh Bhandary wrote:
>> Here is the pg_controldata output from 9.1. Thanks. Dinesh
>>
>> $ /usr/pgsql-9.1/bin/pg_controldata data
>
>> Time of latest checkpoint: Sat 19 Jul 2014 07:02:38 AM GMT
>
>Ah, so you upgraded a month ago, not one week ago, right?
>
>
>> Latest checkpoint's NextMultiXactId: 20783
>
>I'm betting this is the problem. The 9.3 cluster should have
>oldestMulti=20783, but instead it has oldestMulti=1. Either pg_upgrade
>is misreading the nextMulti value from the old cluster, or pg_resetxlog
>is failing to set oldestMulti appropriately ... or something funny
>happened to pg_control in the meantime. I just ran a quick test, and I
>see that pg_upgrade is setting oldestMulti correctly (to the old
>cluster's NextMultiXactId value) in the new cluster when upgrading from
>9.1.
>
>--
>Álvaro Herrera http://www.2ndQuadrant.com/
>PostgreSQL Development, 24x7 Support, Training & Services