From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Logical decoding on standby |
Date: | 2016-11-22 19:55:22 |
Message-ID: | CA+TgmobR0C=iEVo=OQE147myxpP8zbEEENYTN9AJCfMR+6BoDw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 22, 2016 at 1:49 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 22 November 2016 at 10:20, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>> I'm currently looking at making detection of replay conflict with a
>> slot work by separating the current catalog_xmin into two effective
>> parts - the catalog_xmin currently needed by any known slots
>> (ProcArray->replication_slot_catalog_xmin, as now), and the oldest
>> actually valid catalog_xmin where we know we haven't removed anything
>> yet.
>
> OK, more detailed plan.
>
> The last checkpoint's oldestXid, and ShmemVariableCache's oldestXid,
> are already held down by ProcArray's catalog_xmin. But that doesn't
> mean we haven't removed newer tuples from specific relations and
> logged that in xl_heap_clean, etc, including catalogs or user
> catalogs, it only means the clog still exists for those XIDs.
Really?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-11-22 20:18:40 | Re: postgres 9.3 postgres_fdw ::LOG: could not receive data from client: Connection reset by peer |
Previous Message | Robert Haas | 2016-11-22 19:50:17 | Re: Declarative partitioning - another take |