Idea for getting rid of VACUUM FREEZE on cold pages
in [PgSql]
|
Prev: [HACKERS] beta testing - planner bug - ERROR: XX000: failed to build any 2-way joins
Next: [HACKERS] beta testing - pg_upgrade bug fix - double free
From: Tom Lane on 4 Jun 2010 13:35 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. regards, tom lane -- 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: "Kevin Grittner" on 4 Jun 2010 13:52 Tom Lane <tgl(a)sss.pgh.pa.us> 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. Well, are we agreed that the current approach means that insertion of a heap tuple normally requires it to be written to disk three times, with two of those WAL-logged? And that deletion of a tuple generally requires the same? I'd say that constitutes prima facie evidence that any PostgreSQL installation doing any significant number of writes is slower because of this. Are you suggesting there aren't thousands of such installations, or that the repeated disk writes are generally free? -Kevin -- 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: Tom Lane on 4 Jun 2010 15:35 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.) regards, tom lane -- 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: Tom Lane on 4 Jun 2010 16:18 Bruce Momjian <bruce(a)momjian.us> writes: > 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. I already told you my opinion on this matter. Since you're prepared to discount that, I don't see why you'd put any credence in my evidence-free guesses. regards, tom lane -- 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: Alvaro Herrera on 4 Jun 2010 16:27
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. -- Álvaro Herrera <alvherre(a)commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |