Re: Protecting against unexpected zero-pages: proposal

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Protecting against unexpected zero-pages: proposal
Date: 2010-11-09 22:30:09
Message-ID: AANLkTin58_+fvGC=O=PZq28m=uzgTPEvh5B181kZSfjo@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 9, 2010 at 5:03 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 11/9/10 1:50 PM, Robert Haas wrote:
>> 5. It would be pretty much impossible to run with autovacuum turned
>> off, and in fact you would likely need to make it a good deal more
>> aggressive in the specific case of aborted transactions, to mitigate
>> problems #1, #3, and #4.
>
> 6. This would require us to be more aggressive about VACUUMing old-cold
> relations/page, e.g. VACUUM FREEZE.  This it would make one of our worst
> issues for data warehousing even worse.

Uh, no it doesn't. It only requires you to be more aggressive about
vacuuming the transactions that are in the aborted-XIDs array. It
doesn't affect transaction wraparound vacuuming at all, either
positively or negatively. You still have to freeze xmins before they
flip from being in the past to being in the future, but that's it.

> What about having this map (and other hintbits) be per-relation?  Hmmm.
>  That wouldn't work for DDL, I suppose ...

"This map"? I suppose you could track aborted XIDs per relation
instead of globally, but I don't see why that would affect DDL any
differently than anything else.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-11-09 22:30:35 Re: Protecting against unexpected zero-pages: proposal
Previous Message Andrew Dunstan 2010-11-09 22:25:19 Build farm server database migration complete