Thread: Logical decoding on standby
Hi,
If i try to create logical replication slot on standby i get error:
ERROR: logical decoding cannot be used while in recovery
In code i found this comment:
If i try to create logical replication slot on standby i get error:
ERROR: logical decoding cannot be used while in recovery
In code i found this comment:
/* ----
* TODO: We got to change that someday soon...
*
* There's basically three things missing to allow this:
* 1) We need to be able to correctly and quickly identify the timeline a
* LSN belongs to
* 2) We need to force hot_standby_feedback to be enabled at all times so
* the primary cannot remove rows we need.
* 3) support dropping replication slots referring to a database, in
* dbase_redo. There can't be any active ones due to HS recovery
* conflicts, so that should be relatively easy.
* ----
*/
if (RecoveryInProgress())
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("logical decoding cannot be used while in recovery")));
When you plan to add logical decoding on standby?
it is useful to have separate standby server for logical replication that will not break the master if you make a mistake in plugin.
--
Regards
Dmitriy
Hi Dimitriy,
Дмитрий Сарафанников wrote:
> /* ----
> * TODO: We got to change that someday soon...
[ more code ]
> if (RecoveryInProgress())
> ereport(ERROR,
> (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> errmsg("logical decoding cannot be used while in recovery")));
> When you plan to add logical decoding on standby?
Things change as people submit patches to make them change. If you want
this changed, you could either write a patch yourself, or persuade
someone else to do it for you.
I don't think anyone is working in this particular TODO just yet -- as I
know, all the logical-decoding-enabled developers are pretty busy doing
other things. The good news is that the things that need doing are
spelled right there in the comment :-)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 19 January 2016 at 23:30, Дмитрий Сарафанников <dimon99901@mail.ru> wrote:
When you plan to add logical decoding on standby?
it is useful to have separate standby server for logical replication that will not break the master if you make a mistake in plugin.
Indeed. It might PANIC it and force a restart, if that's what you mean. I guess in an extreme case you could clobber shmem silently, which would be bad. (I wonder if we could make shared_buffers mmap'ed read-only for walsender backends?). So it certainly seems like it'd be nice to have. There's also the advantage that you could shift load off the master by having physical master=>replica replication on a fast wide link, then do logical decoding from there to send over the wire to WAN sites etc.
Unfortunately it's not particularly simple and nobody seems to have time to implement it. As Álvaro pointed out, sometimes you have to do the work if you want the change to happen. Or find someone with the existing skills and convince them to want to do it, but most of those people are already very, very busy.
As part of the failover slots work Simon noted that:
"To prevent needed rows from being removed we need we would need to enhance hot_standby_feedback so it sends both xmin and catalog_xmin to the master."
... which means a protocol change in the walsender protocol. So you're looking at that plus the other comment given above, that
"We need to be able to correctly and quickly identify the timeline a LSN belongs to"
.... which is new internal infrastructure and new state in the replica that must be maintained. Probably persistently.
In other words ... this isn't especially simple to do. It requires at least two non-trivial core changes. Nobody who has the skills to do it reasonably quickly also has the time to do it at all or has other higher priority things to do first. So it's not likely to happen soon unless you or someone like you steps up and has a go at it.
If you do decide to attempt to implement it and you're willing to read a fair bit of code and documentation to do so you'll find people here pretty helpful with suggestions, ideas, and help if you get stuck. But only if you put in the work yourself.
(On a side note, failover slots probably won't be usable from a standby either. They have to write to WAL and you can't write to WAL from a standby. So if slot support is ever added on a standby it'll probably be ephemeral slots only.)
On 2016-01-20 15:11:06 +0800, Craig Ringer wrote: > Unfortunately it's not particularly simple and nobody seems to have time to > implement it. FWIW, I don't think it's *that* hard. > As Álvaro pointed out, sometimes you have to do the work if > you want the change to happen. Or find someone with the existing skills and > convince them to want to do it, but most of those people are already very, > very busy. > > As part of the failover slots work Simon noted that: > > "To prevent needed rows from being removed we need we would need to enhance > hot_standby_feedback so it sends both xmin and catalog_xmin to the master." > > ... which means a protocol change in the walsender protocol. So you're > looking at that plus the other comment given above, that Not a huge problem though. > "We need to be able to correctly and quickly identify the timeline a LSN > belongs to" > > .... which is new internal infrastructure and new state in the replica that > must be maintained. Probably persistently. I think it just needs a more efficient lookup structure over the existing tliOfPointInHistory(), the data is all there. > (On a side note, failover slots probably won't be usable from a standby > either. They have to write to WAL and you can't write to WAL from a > standby. So if slot support is ever added on a standby it'll probably be > ephemeral slots only.) ephemeral slots are a different thing. Anyway, at this point failover slots aren't really proposed / have an agreed upon design yet, so it's a bit hard to take them into account. Greetings, Andres Freund