Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 87A8A47626C for ; Mon, 30 Sep 2002 10:37:12 -0400 (EDT) Received: from new-smtp2.ihug.com.au (new-smtp2.ihug.com.au [203.109.250.28]) by postgresql.org (Postfix) with ESMTP id C5662476216 for ; Mon, 30 Sep 2002 10:37:11 -0400 (EDT) Received: from p205-tnt2.mel.ihug.com.au (postgresql.org) [203.173.164.205] by new-smtp2.ihug.com.au with esmtp (Exim 3.22 #1 (Debian)) id 17w1fe-0006jK-00; Tue, 01 Oct 2002 00:37:15 +1000 Message-ID: <3D986199.37863C69@postgresql.org> Date: Tue, 01 Oct 2002 00:37:13 +1000 From: Justin Clift X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Momjian Cc: Tom Lane , pgsql-hackers@postgresql.org Subject: Re: Cause of missing pg_clog files References: <200209280030.g8S0UcR16258@candle.pha.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200209/1774 X-Sequence-Number: 29731 Bruce Momjian wrote: > > 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. We definitely should have a 7.2.3. If we can release a 7.2.2 to fix bugs and a security flaw, then we should definitely have a 7.2.3 to ensure the usability of the 7.2.x series. Some places will still be using 7.2.x for 2 years to come, just because 7.2.x was what their projects started developing against, etc. :-) Regards and best wishes, Justin Clift > --------------------------------------------------------------------------- > > 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@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi