From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, hlinnaka <hlinnaka(at)iki(dot)fi>, Bruce Momjian <bruce(at)momjian(dot)us>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Subject: | Re: Reducing tuple overhead |
Date: | 2015-04-30 03:07:18 |
Message-ID: | 20150430030718.GO4369@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas wrote:
> On Mon, Apr 27, 2015 at 5:01 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> > The problem with just having the value is that if *anything* changes between
> > how you evaluated the value when you created the index tuple and when you
> > evaluate it a second time you'll corrupt your index. This is actually an
> > incredibly easy problem to have; witness how we allowed indexing
> > timestamptz::date until very recently. That was clearly broken, but because
> > we never attempted to re-run the index expression to do vacuuming at least
> > we never corrupted the index itself.
>
> True. But I guess what I don't understand is: how big a deal is this,
> really? The "uncorrupted" index can still return wrong answers to
> queries. The fact that you won't end up with index entries pointing
> to completely unrelated tuples is nice, but if index scans are missing
> tuples that they should see, aren't you still pretty hosed?
As I recall, there's a desire not to run expressions when vacuuming,
because to run them means getting a snapshot, in case any functions look
at database state; and you can't get a snapshot while vacuuming because
that means the vacuum gets visible to concurrent processes; in
particular they keep all processes' xmin from moving forward.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2015-04-30 03:17:22 | Re: Make more portable TAP tests of initdb |
Previous Message | Alvaro Herrera | 2015-04-30 02:59:26 | Re: pg_upgrade: quote directory names in delete_old_cluster script |