Re: Timeline following for logical slots - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: Timeline following for logical slots
Date
Msg-id 570476E2.6000505@2ndquadrant.com
Whole thread Raw
In response to Re: Timeline following for logical slots  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Timeline following for logical slots  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On 06/04/16 03:29, Robert Haas wrote:
>
>> I don't understand why it seems to be considered OK for logical slots to
>> just vanish on failover. The only other things I can think of where that's
>> considered OK are unlogged tables (because that's the point and we have
>> failover-safe ones too) and the old hash indexes nobody's quite willing to
>> remove yet.
>
> First, it wasn't until 9.3 that physical standbys could follow
> timeline switches, but that doesn't mean that streaming replication
> was useless in 9.0 - 9.2, or that warm standby was useless in earlier
> versions.  Logical decoding isn't useless without that capability
> either.  Would it be nice if we did have that capability?  Of course.
>

Except that in 9.0 - 9.2 there was working workaround for that, there is 
no such thing for logical decoding.

> Second, I'm not sure whether it was a good design decision to make
> logical slots a special kind of object that sit off to the side,
> neither configuration (like postgresql.conf) nor WAL-protected data
> (like pg_clog and the data files themselves), but it was certainly a
> very deliberate decision.  I sort of expected them to be WAL-logged,
> but Andres argued (not unconvincingly) that we'd want to have slots on
> standbys, and making them WAL-logged would preclude that.

I do think it was good design decision. We just need to make them 
failoverable bit differently and the failover slots patch IMHO isn't the 
right way either as I said in another reply in this thread.

>
>> Review and test responses have been pretty underwhelming for pglogical, and
>> quite a bit seem to have boiled down to "this should live as an extension,
>> we don't need it in core". It often feels like we can't win: if we seek to
>> get it into core we're told it's not wanted/needed, but if we try to focus
>> on solving issues in core to make it work better and let it live as an
>> extension we're told we shouldn't bother until it's in core.
>
> To be honest, I was shocked that pglogical and pglogical_output didn't
> go into this release.  I assumed that you and other folks at
> 2ndQuadrant were going to make a big push to get that done.  I did
> take a brief look at one of them - pglogical, I think - a week or two
> ago but there were unaddressed review comments that had been pending
> for months and there were a lot of fairly obvious things that needed
> to be done before it could be seriously considered as a core
> submission.  Like, for example, rewriting the documentation heavily
> and making it look like the rest of our docs, and putting it in SGML
> format.  The code seemed to need quite a bit of cleanup, too.  Now,
> logical replication is a sufficiently important feature that if the
> only way it's going to get into core is if I work on it myself, or get
> other people at EnterpriseDB to do so, then I'll try to make that
> happen.  But I was assuming that that was your/2ndQuadrant's patch,
> that you were going to get it in shape, and that me poking my nose
> into it wasn't going to be particularly welcome.  Maybe I've misread
> the whole dynamic here.

I guess you did, me and I think Craig as well hoped for some feedback on 
the general ideas in terms of protocol, node setup (I mean catalogs) and 
general architecture from the community. That didn't really happen. And 
without any of that happening I didn't feel confident trying to get it 
right within last month of dev cycle. Especially given the size of the 
patch and the fact we also had other patches that we worked on and had 
realistically higher chance of getting in. Not sure how Craig feels 
about it. Converting documentation, renaming some params in function 
names etc (those unaddressed comments) seemed like secondary to me.

(As a side note I was also 2 weeks without proper working laptop around 
FOSDEM time which had effect on my responses to -hackers about the 
topic, especially to Steve Singer who did good job of reviewing the 
usability at the time, but even if I had it it would not saved the patch)

In general I think project of this size requires more attention from 
committer to help shepherding it and neither Craig or me are that. I am 
glad that Andres said he plans to give some time in next cycle to 
logical replication because that should be big help.

>
> That being said, if we get a logical replication system into core that
> doesn't do DDL, doesn't do multi-master, doesn't know squat about
> sequences, and rolls over and dies if a timeline switch happens, I
> would consider that a huge step forward and I think a lot of other
> people would, too.

I agree with the exception of working HA. I would consider it very sad 
if we got logical replication in core without having any provision for 
continuity of service. Doing that is relatively trivial in comparison to 
the logical replication itself however.

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



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Timeline following for logical slots
Next
From: Craig Ringer
Date:
Subject: Re: WIP: Failover Slots