Обсуждение: Logical decoding on standby
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
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.
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