Cause of missing pg_clog files
От | Tom Lane |
---|---|
Тема | Cause of missing pg_clog files |
Дата | |
Msg-id | 8183.1033166430@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Cause of missing pg_clog files
Re: Cause of missing pg_clog files |
Список | 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
В списке pgsql-hackers по дате отправления: