Re: Hot Standby (commit fest version - v5) - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Hot Standby (commit fest version - v5)
Date
Msg-id 2e78013d0811200306v18778181oec359db21f1c6761@mail.gmail.com
Whole thread Raw
In response to Re: Hot Standby (commit fest version - v5)  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers


On Thu, Nov 20, 2008 at 3:38 PM, Simon Riggs <simon@2ndquadrant.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

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Transactions and temp tables
Next
From: Grzegorz Jaskiewicz
Date:
Subject: Re: Updated posix fadvise patch v19