Skip site navigation (1) Skip section navigation (2)

Re: Cause of missing pg_clog files

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Cause of missing pg_clog files
Date: 2002-09-28 00:30:38
Message-ID: 200209280030.g8S0UcR16258@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
OK, we need a decision on whether we are going to do a 7.2,3 or just
have it in beta3.  If it is in 7.2.3, I would not mention it in the
beta3 release notes.

---------------------------------------------------------------------------

Tom Lane wrote:
> Yesterday I reported a WAL problem that could lead to tuples not being
> marked as committed-good or committed-dead after we'd already removed
> the pg_clog segment that had their transaction's commit status.
> I wasn't completely satisfied with that, though, because on further
> reflection it seemed a very low-probability mechanism.  I kept digging,
> and finally came to the kind of bug that qualifies as a big DOH :-(
> 
> If you run a database-wide VACUUM (one with no specific target table
> mentioned) as a non-superuser, then the VACUUM doesn't process tables
> that don't belong to you.  But it will advance pg_database.datvacuumxid
> anyway, which means that pg_clog could be truncated while old transaction
> references still remain unmarked in those other tables.
> 
> In words of one syllable: running VACUUM as a non-superuser can cause
> irrecoverable data loss in any 7.2.* release.
> 
> I think this qualifies as a "must fix" bug.  I recommend we back-patch
> a fix for this into the REL7_2 branch and put out a 7.2.3 release.
> We should also fix the "can't wait without a PROC" bug that was solved
> a few days ago.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-hackers by date

Next:From: Mark KirkwoodDate: 2002-09-28 01:38:52
Subject: Re: Performance while loading data and indexing
Previous:From: Bruce MomjianDate: 2002-09-28 00:08:26
Subject: Re: Cause of missing pg_clog files

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group