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

From Craig Ringer
Subject Re: [HACKERS] Logical decoding on standby
Date
Msg-id CAMsr+YHCca+Cry_JoWGDHtpCR-ysD=y=KRefOLG9WS-semMZuA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Logical decoding on standby  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Logical decoding on standby  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 22 March 2017 at 21:06, Andres Freund <andres@anarazel.de> wrote:
> 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.

Definitely beneficial, otherwise recovery will stop until you drop
slots, which isn't ideal.

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

Yes, and to update restart_lsn and catalog_xmin correctly.

I was thinking that by disallowing snapshot use and output plugin
invocation we'd avoid the need to support cancellation on recovery
conflicts, etc, simplifying things considerably.

>> * Ability to drop logical slots on replicas
>
> That shouldn't actually require any changes, no?

It doesn't, it works as-is. I have NFI why I wrote that.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Logical decoding on standby