From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | "Wood, Dan" <hexpert(at)amazon(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "Wong, Yi Wen" <yiwong(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Subject: | Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple |
Date: | 2017-10-06 19:27:26 |
Message-ID: | CAH2-WzkR0m4ZBrPgvUF2GaLQtwimN6xhXBbGzBc51mNfZeo73w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Fri, Oct 6, 2017 at 11:34 AM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>> I don't know if it's really the freeze map at fault or something else.
>
> Ideally, it would be possible to effectively disable the new freeze
> map stuff in a minimal way, for testing purposes. Perhaps the authors
> of that patch, CC'd, can suggest a way to do that.
Actually, the simplest thing might be to just use pg_visibility's
pg_check_frozen() to check that the visibility/freeze map accurately
summarizes the all-frozen status of tuples in the heap. If that
doesn't indicate that there is corruption, we can be fairly confident
that the problem is elsewhere. The metadata in the visibility/freeze
map should be accurate when a bit is set to indicate that an entire
heap page is all-frozen (or, separately, all-visible). We can hardly
expect it to have better information that the authoritative source of
truth, the heap itself.
The more I think about it, the more I tend to doubt that the remaining
problems are with the freeze map. If the freeze map was wrong, and
incorrectly said that a page was all-frozen, then surely the outward
symptoms would take a long time to show up, as they always do when we
accidentally fail to freeze a tuple before a relfrozenxid cutoff. ISTM
that that's the only meaningful way that the freeze map can be wrong
-- it only promises to be accurate when it says that no further
freezing is needed for a page/bit.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-10-06 19:33:22 | pgsql: Copy information from the relcache instead of pointing to it. |
Previous Message | Peter Geoghegan | 2017-10-06 18:34:20 | Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-10-06 19:34:05 | Re: Partition-wise join for join between (declaratively) partitioned tables |
Previous Message | Mike Rylander | 2017-10-06 19:22:52 | Re: [PROPOSAL] Temporal query processing with range types |