Re: [HACKERS] Logical decoding on standby - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Logical decoding on standby
Date
Msg-id 20170322130619.avxnxxpaut5qfwln@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Logical decoding on standby  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [HACKERS] Logical decoding on standby  (Simon Riggs <simon.riggs@2ndquadrant.com>)
Re: [HACKERS] Logical decoding on standby  (Simon Riggs <simon.riggs@2ndquadrant.com>)
Re: [HACKERS] Logical decoding on standby  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
Hi,

On 2017-03-21 09:05:26 +0800, Craig Ringer wrote:
> > 0002 should be doable as a whole this release, I have severe doubts that
> > 0003 as a whole has a chance for 10 - the code is in quite a raw shape,
> > there's a significant number of open ends.  I'd suggest breaking of bits
> > that are independently useful, and work on getting those committed.
> 
> That would be my preference too.


> The parts I think are important for Pg10 are:

> * Ability to create logical slots on replicas

Doesn't this also imply recovery conflicts on DROP DATABASE?  Besides,
allowing to drop all slots using a database upon DROP DATABASE, is a
useful thing on its own.

But I have to admit, I've *severe* doubts about getting the whole
infrastructure for slot creation on replica into 10.  The work is far
from ready, and we're mere days away from freeze.


> * Ability to advance (via feedback or via SQL function) - no need to
> actually decode and call output plugins at al

That pretty much requires decoding, otherwise you really don't know how
much WAL you have to retain.


> * Ability to drop logical slots on replicas

That shouldn't actually require any changes, no?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Monitoring roles patch