Re: Old row version in hot chain become visible after a freeze

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: "Wong, Yi Wen" <yiwong(at)amazon(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, "Wood, Dan" <hexpert(at)amazon(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Old row version in hot chain become visible after a freeze
Date: 2017-09-08 16:42:44
Message-ID: 20170908164244.5oi6rcvy5ut7dpkb@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Wong, Yi Wen wrote:

> There is actually another case where HEAPTUPLE_DEAD tuples may be kept and have
> prepare_freeze skipped on them entirely.
>
> lazy_record_dead_tuple may fail to record the heap for later pruning
> for lazy_vacuum_heap if there is already a sufficiently large number of dead tuples
> in the array:

Hmm, ouch, good catch.

AFAICS this is a shouldn't-happen condition, since we bail out of the
loop pessimistically as soon as we would be over the array limit if the
next page were to be full of dead tuples (i.e., we never give the chance
for overflow to actually happen). So unless I misunderstand, this could
only fail if you give maint_work_mem smaller than necessary for one
pageful of dead tuples, which should be about 1800 bytes ...

If we wanted to be very sure about this we could add a test and perhaps
abort the vacuum, but I'm not sure it's worth the trouble.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2017-09-08 17:04:10 Re: Old row version in hot chain become visible after a freeze
Previous Message Tom Lane 2017-09-08 14:24:45 Re: BUG #14806: WAL replay on standby: could not link file "pg_xlog/...4C" to "pg_xlog/...D1": File exists