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
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 |