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

Cause of missing pg_clog files

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Cause of missing pg_clog files
Date: 2002-09-27 22:40:30
Message-ID: 8183.1033166430@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-09-28 00:08:26
Subject: Re: Cause of missing pg_clog files
Previous:From: Florian WeimerDate: 2002-09-27 19:01:38
Subject: Re: [GENERAL] Performance while loading data and indexing

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