Re: Timeline following for logical slots

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Timeline following for logical slots
Date: 2016-04-06 02:39:30
Message-ID: 570476E2.6000505@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2016-04-06 02:41:54 Re: WIP: Failover Slots
Previous Message Craig Ringer 2016-04-06 02:34:35 Re: Timeline following for logical slots