"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> On Wed, Sep 10, 2008 at 9:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> On reflection I'm not even sure that this is strictly an autovacuum
>> bug. It can be cast more generically as "RecentGlobalXmin getting
>> used without ever having been set", and it sure looks to me like the
>> HOT patch may have introduced a few risks of that sort.
> ISTM that HOT may be safe here because even if RecentGlobalXmin is not
> set and has the boot time value of FirstNormalTransactionId, the
> heap_page_prune_opt() would just return without doing any real work.
Until the XID counter advances past the 2billion mark. Then the
uninitialized RecentGlobalXmin would be "in the future" and would
result in mistaken decisions *to* prune, not to not prune.
In short this is a risk-of-data-loss bug. Once the patch is in
I think we ought to start thinking about a set of update releases...
regards, tom lane