Idea for getting rid of VACUUM FREEZE on coldpages
in [PgSql]
|
Prev: recovery getting interrupted is not so unusual as it used to be
Next: ALTER TABLE .... make constraint DEFERRABLE
From: Bruce Momjian on 2 Jun 2010 19:22 Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mié jun 02 14:16:33 -0400 2010: > > > We could, but I think we'd be better off just freezing at the time we > > mark the page PD_ALL_VISIBLE and then using the visibility map for > > both purposes. Keeping around the old xmin values after every tuple > > on the page is visible to every running transaction is useful only for > > forensics, and building a whole new freeze map just to retain that > > information longer (and eventually force a massive anti-wraparound > > vacuum) seems like overkill. > > Reducing the xid wraparound horizon "a bit" is reasonable, but moving it > all the way forward to OldestXmin is a bit much, methinks. > > Besides, there's another argument for not freezing tuples immediately: > they may be updated shortly thereafter, causing extra churn for no gain. > > I'd prefer a setting that would tell the system to freeze all tuples > that fall within a safety range whenever any tuple in the page is frozen > -- weren't you working on a patch to do this? (was it Jeff Davis?) > > (BTW maybe instead of separate visibility and freeze maps we could have > two bits in the visibility map?) Yeah, the two-bits idea was suggested during the conversation core had about the issue. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 4 Jun 2010 13:57 Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > > The idea that thousands of Postgres installations are slower just so we > > can occasionally debug xmin/xmax issues seems way off balance to me. > > There's no evidence whatsoever that the scope of the problem is that large. > > > If people want debugging, let them modify the freeze age settings; the > > defaults should not favor debugging when there is a measurable cost > > involved. How many times in the past five years have we even needed > > such debugging information, and also are cases where we could not have > > told the user to change freeze settings to get us that info? > > You're missing the point here: this is something we need when trying > to make sense of cases that are hard or impossible to reproduce. > Retroactively changing the freeze policy isn't possible. With in-place VACUUM FULL gone in 9.0, will there be as much need for xmin/xmax forensics? -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 4 Jun 2010 12:23 Kevin Grittner wrote: > Fair enough. I was thinking of them both as debugging features, > which had various ideas roiling around in my head. Having run > hundreds of databases 24/7 for years without ever needing this > information, but paying the cost for it one way or another every > day, my perspective is that it would be A Good Thing if it could > just be turned on when needed. If you have recurring bug that can > be arranged, but in those cases you have other options; so I'm > assuming you want this kept because it is primarily of forensic > value after a non-repeatable bug has munged something? > > Another thought bouncing around was that these breadcrumbs are > expensive; I was trying to think of some other way to capture the > information which would be cheaper, but I haven't thought of > anything, and I'm far from certain that cheaper breadcrumbs to > answer the need can be developed. The best thought I've had so far > is that if someone kept WAL files long enough the evidence might be > in there somewhere.... The idea that thousands of Postgres installations are slower just so we can occasionally debug xmin/xmax issues seems way off balance to me. If people want debugging, let them modify the freeze age settings; the defaults should not favor debugging when there is a measurable cost involved. How many times in the past five years have we even needed such debugging information, and also are cases where we could not have told the user to change freeze settings to get us that info? -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 4 Jun 2010 15:39 Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > > With in-place VACUUM FULL gone in 9.0, will there be as much need for > > xmin/xmax forensics? > > You know perfectly well that no one could answer that question. > (Or at least not answer it on the basis of facts available today.) Well, guess then. In the past, how many forensic cases were needed for in-place VACUUM FULL bugs, vs. other cases? -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 4 Jun 2010 16:35
Alvaro Herrera wrote: > Excerpts from Bruce Momjian's message of vie jun 04 15:39:07 -0400 2010: > > Tom Lane wrote: > > > Bruce Momjian <bruce(a)momjian.us> writes: > > > > With in-place VACUUM FULL gone in 9.0, will there be as much need for > > > > xmin/xmax forensics? > > > > > > You know perfectly well that no one could answer that question. > > > (Or at least not answer it on the basis of facts available today.) > > > > Well, guess then. In the past, how many forensic cases were needed for > > in-place VACUUM FULL bugs, vs. other cases? > > I don't understand the question. I know I have debugged a bunch of > cases of data corruption, and having xmin/xmax around has been truly > useful. VACUUM FULL has never been involved (that I know of -- most of > our customers tend not to run it AFAIK), so why would I care about > whether it's gone in 9.0? Note that it's not always about PG bugs; but > in the cases where xmin=FrozenXid for all/most involved tuples, the > problems are more difficult to track down. > > Yes, VACUUM FULL had bugs too -- I, for one, welcome our new > not-in-place VACUUM FULL overlord. OK, so we had lots of forensics the didn't involve VACUUM FULL. That's what I wanted to know. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |