| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: New vacuum option to do only freezing |
| Date: | 2019-04-16 01:07:16 |
| Message-ID: | 28991.1555376836@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Apr 15, 2019 at 3:47 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> No. I'm thinking there should be exactly one test of index_cleanup
>> in this logic, and what it would be is along the lines of ...
> I'm not sure that's correct. If you do that, it'll end up in the
> non-tupgone case, which might try to freeze a tuple that should've
> been removed. Or am I confused?
If we're failing to remove it, and it's below the desired freeze
horizon, then we'd darn well better freeze it instead, no?
Since we know that the tuple only just became dead, I suspect
that the case would be unreachable in practice. But the approach
you propose risks violating the invariant that all old tuples
will either be removed or frozen.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jamison, Kirk | 2019-04-16 01:48:37 | RE: Speedup of relation deletes during recovery |
| Previous Message | Robert Haas | 2019-04-16 01:04:13 | Re: finding changed blocks using WAL scanning |