Re: Protecting against unexpected zero-pages: proposal

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Protecting against unexpected zero-pages: proposal
Date: 2010-11-09 22:30:35
Message-ID: AANLkTi=1_ucX0z_wB5hmHomPG14zZrvoEcN6xssGwaDP@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 9, 2010 at 5:15 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> 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.
>
> I continue to feel that it is insane that when a table is populated
> within the same database transaction which created it (e.g., a bulk
> load of a table or partition), that we don't write the tuples with
> hint bits set for commit and xmin frozen.  By the time any but the
> creating transaction can see the tuples, *if* any other transaction
> is ever able to see the tuples, these will be the correct values;
> we really should be able to deal with it within the creating
> transaction somehow.

I agree.

> If we ever handle that, would #6 be a moot point, or do you think
> it's still a significant issue?

I think it's a moot point anyway, per previous email.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-11-09 22:41:26 Re: Protecting against unexpected zero-pages: proposal
Previous Message Robert Haas 2010-11-09 22:30:09 Re: Protecting against unexpected zero-pages: proposal