pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedCause of missing pg_clog files
6+ messages / 4 participants
[nested] [flat]
* Cause of missing pg_clog files
@ 2002-09-27 22:40 Tom Lane <tgl@sss.pgh.pa.us>
2002-09-28 00:08 ` Re: Cause of missing pg_clog files Bruce Momjian <pgman@candle.pha.pa.us>
2002-09-28 00:30 ` Re: Cause of missing pg_clog files Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 2 replies; 6+ messages in thread
From: Tom Lane @ 2002-09-27 22:40 UTC (permalink / raw)
To: 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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Cause of missing pg_clog files
2002-09-27 22:40 Cause of missing pg_clog files Tom Lane <tgl@sss.pgh.pa.us>
@ 2002-09-28 00:08 ` Bruce Momjian <pgman@candle.pha.pa.us>
1 sibling, 0 replies; 6+ messages in thread
From: Bruce Momjian @ 2002-09-28 00:08 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
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.
Wow, you sure have found some good bugs in the past few days. Nice job.
Yes, I agree we should push out a 7.2.3, and I think we are now ready
for beta3. I will work on docs and packaging now.
--
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Cause of missing pg_clog files
2002-09-27 22:40 Cause of missing pg_clog files Tom Lane <tgl@sss.pgh.pa.us>
@ 2002-09-28 00:30 ` Bruce Momjian <pgman@candle.pha.pa.us>
2002-09-30 14:31 ` Re: Cause of missing pg_clog files Andrew Sullivan <andrew@libertyrms.info>
2002-09-30 14:37 ` Re: Cause of missing pg_clog files Justin Clift <justin@postgresql.org>
1 sibling, 2 replies; 6+ messages in thread
From: Bruce Momjian @ 2002-09-28 00:30 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: 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@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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Cause of missing pg_clog files
2002-09-27 22:40 Cause of missing pg_clog files Tom Lane <tgl@sss.pgh.pa.us>
2002-09-28 00:30 ` Re: Cause of missing pg_clog files Bruce Momjian <pgman@candle.pha.pa.us>
@ 2002-09-30 14:31 ` Andrew Sullivan <andrew@libertyrms.info>
1 sibling, 0 replies; 6+ messages in thread
From: Andrew Sullivan @ 2002-09-30 14:31 UTC (permalink / raw)
To: pgsql-hackers
On Fri, Sep 27, 2002 at 08:30:38PM -0400, 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.
If there won't be any 7.2.3, could a note be put up on the website at
least? This is a pretty serious problem, and new users right now
will be using 7.2.2, which has this bug. They should be warned.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Cause of missing pg_clog files
2002-09-27 22:40 Cause of missing pg_clog files Tom Lane <tgl@sss.pgh.pa.us>
2002-09-28 00:30 ` Re: Cause of missing pg_clog files Bruce Momjian <pgman@candle.pha.pa.us>
@ 2002-09-30 14:37 ` Justin Clift <justin@postgresql.org>
2002-09-30 15:09 ` Re: Cause of missing pg_clog files Bruce Momjian <pgman@candle.pha.pa.us>
1 sibling, 1 reply; 6+ messages in thread
From: Justin Clift @ 2002-09-30 14:37 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Cause of missing pg_clog files
2002-09-27 22:40 Cause of missing pg_clog files Tom Lane <tgl@sss.pgh.pa.us>
2002-09-28 00:30 ` Re: Cause of missing pg_clog files Bruce Momjian <pgman@candle.pha.pa.us>
2002-09-30 14:37 ` Re: Cause of missing pg_clog files Justin Clift <justin@postgresql.org>
@ 2002-09-30 15:09 ` Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 0 replies; 6+ messages in thread
From: Bruce Momjian @ 2002-09-30 15:09 UTC (permalink / raw)
To: Justin Clift <justin@postgresql.org>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Justin Clift wrote:
> 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.
There will be a 7.2.3. Tom is going to back-port his fixes, then I am
going to brand it, and then Marc will release it; it is in-process.
--
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
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2002-09-30 15:09 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2002-09-27 22:40 Cause of missing pg_clog files Tom Lane <tgl@sss.pgh.pa.us>
2002-09-28 00:08 ` Bruce Momjian <pgman@candle.pha.pa.us>
2002-09-28 00:30 ` Bruce Momjian <pgman@candle.pha.pa.us>
2002-09-30 14:31 ` Andrew Sullivan <andrew@libertyrms.info>
2002-09-30 14:37 ` Justin Clift <justin@postgresql.org>
2002-09-30 15:09 ` Bruce Momjian <pgman@candle.pha.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox