On Thu, Apr 7, 2011 at 5:52 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Jeff Davis wrote:
>> On Thu, 2011-04-07 at 12:38 -0700, Jeff Davis wrote:
>> > > Any idea how to correct existing systems? Would VACUUM FREEZE of just
>> > > the toast tables work?
>> >
>> > VACUUM FREEZE will never set the relfrozenxid backward. If it was never
>> > preserved to begin with, I assume that the existing value could be
>> > arbitrarily before or after, so it might not be updated.
>>
>> Now that I understand the problem a little better, I think VACUUM FREEZE
>> might work, after all.
>
> Good. I don't want to be inventing something complex if I can avoid it.
> Simple is good, espeically if admins panic. I would rather simple and
> longer than short but complex :-)
>
>> Originally, I thought that the toast table's relfrozenxid could be some
>> arbitrarily wrong value. But actually, the CREATE TABLE is issued after
>> the xid of the new cluster has already been advanced to the xid of the
>> old cluster, so it should be a "somewhat reasonable" value.
>
> Yes, it will be reasonable.
>
>> That means that VACUUM FREEZE of the toast table, if there are no
>> concurrent transactions, will freeze all of the tuples; and the
>> newFrozenXid should always be seen as newer than the existing (and
>> wrong) relfrozenxid. Then, it will set relfrozenxid to newFrozenXid and
>> everything should be fine. Right?
>
> Right.
This depends on how soon after the upgrade VACUUM FREEZE is run,
doesn't it? If the XID counter has advanced too far...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company