Re: Hot Standby (commit fest version - v5)

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot Standby (commit fest version - v5)
Date: 2008-11-20 11:06:20
Message-ID: 2e78013d0811200306v18778181oec359db21f1c6761@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 20, 2008 at 3:38 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

>
> I would suggest that we just remove the switch statement:
> switch (HeapTupleSatisfiesVacuum(tuple.t_data, OldestXmin, buf))
> and alter the following if test since tupgone is also removed.
> That will cause HEAPTUPLE_DEAD rows to be fed to heap_freeze_tuple().
> Comments on that function claim that is a bad thing, but we know that
> any row that was *not* removed by heap_page_prune() and is now dead must
> have died very recently and so will never be frozen.
>
> Let me know if you're happy with that change and I'll make it so.
>
>

Yeah, I think we should be safe. We continuously hold EX lock on the buffer
since the prune operation is carried out. So the only new DEAD tuples may
arrive because some transaction aborted in between, changing
INSERT_IN_PROGRESS tuple to DEAD. But these tuples won't pass the cutoff_xid
test and should never be frozen.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Grzegorz Jaskiewicz 2008-11-20 11:08:47 Re: Updated posix fadvise patch v19
Previous Message Heikki Linnakangas 2008-11-20 11:02:45 Re: Transactions and temp tables