Re: Missing tables in postgresql 7.2.4

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Michael Beckstette" <mbeckste(at)TechFak(dot)Uni-Bielefeld(dot)DE>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Missing tables in postgresql 7.2.4
Date: 2005-05-12 05:05:06
Message-ID: 26962.1115874306@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Michael Beckstette" <mbeckste(at)TechFak(dot)Uni-Bielefeld(dot)DE> writes:
> On May 11, 2:39pm, Tom Lane wrote:
>> If it does, go ahead and do a database-wide plain VACUUM, and you
>> should be OK.

> Done. As far as I can tell, everything is OK again.

Sweet ;-) In the words of my former business partner, a private pilot
with more hours aloft than many airline captains: "Walked away from
another one ..."

For the benefit of onlookers, the gambit being played here went like
this: the missing pg_class rows must have fairly recently wrapped around
the 2G transaction mark with respect to the current XID counter. That
made them "in the future" not "in the past" as far as normal queries
go. However, a VACUUM will freeze-as-good any tuples that are "in the
past" with respect to the vacuum freeze time, which for a plain VACUUM
is 1G transactions ago. So as long as Michael notices he has a problem
within 1 billion transactions of having a problem, he can get out of it.

I cannot claim that this behavior was operating-as-designed, because
I'm pretty sure we hadn't thought it through when planning the
wraparound XID behavior. But we walked away from another one.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Sankaran Anupama 2005-05-12 05:35:16 Do dropdb and createdb read password from .pgpass file?
Previous Message JK 2005-05-12 03:35:28 BUG #1663: postgresql-8.0.msi Fails to Install