From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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 03:57:53 |
Message-ID: | 20190416035753.GD2673@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 15, 2019 at 09:07:16PM -0400, Tom Lane wrote:
> 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.
Please note that I have added an open item for this investigation (see
"topminnow triggered assertion failure with vacuum_index_cleanup").
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-04-16 04:36:41 | Re: [PATCH v20] GSSAPI encryption support |
Previous Message | Michael Paquier | 2019-04-16 03:45:35 | Re: finding changed blocks using WAL scanning |