From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot Standby: too many KnownAssignedXids |
Date: | 2010-12-02 10:41:39 |
Message-ID: | 4CF777E3.2090701@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02.12.2010 11:02, Simon Riggs wrote:
> The cause of the issue is that replay starts at one LSN and there is a
> delay until the RunningXacts WAL record occurs. If there was no delay,
> there would be no issue at all. In CreateCheckpoint() we start by
> grabbing the WAInsertLock and later recording that pointer as part of
> the checkpoint record. My proposal is to replace the "grab the lock"
> code with the insert of the RunningXacts WAL record (when wal_level
> set), so that recovery always starts with that record type.
Oh, interesting idea. But AFAICS closing the gap between acquiring the
running-xacts snapshot and writing it to the log is sufficient, I don't
see what moving the running-xacts record buys us. Does it allow some
further simplifications somewhere?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2010-12-02 11:00:09 | Re: pg_execute_from_file review |
Previous Message | Yeb Havinga | 2010-12-02 10:30:59 | Re: FK's to refer to rows in inheritance child |