Re: logical replication snapshots
От | Dimitri Maziuk |
---|---|
Тема | Re: logical replication snapshots |
Дата | |
Msg-id | 5c10ced3-7e1a-d673-1da9-d45985bf37f5@bmrb.wisc.edu обсуждение исходный текст |
Ответ на | Re: logical replication snapshots (Adrian Klaver <adrian.klaver@aklaver.com>) |
Ответы |
Re: logical replication snapshots
|
Список | pgsql-general |
On 07/26/2018 07:11 PM, Adrian Klaver wrote: > On 07/26/2018 04:48 PM, Dimitri Maziuk wrote: ... >> The publication foopub is at this point fubar I take it? And needs to be >> re-created on the publisher and reconnected on the subscriber? Complete >> with with inital resync? > > Not sure. Personally I would try: > > 1) ALTER PUBLICATION DROP TABLE foo|bar; > > 2) ALTER PUBLICATION ADD TABLE foo|bar; > > 3) ALTER SUBSCRIPTION sub_name REFRESH PUBLICATION > > If you get to 3) it will re-sync the data unless you tell it otherwise. > > The above is probably dependent on the size of the publication. If you > did a publication for ALL it would make more sense to do the above then > if you did a publication for just foo or bar. ... but if I did the publication for ALL, I could just use streaming replication and then drop table/add table would replicate automagically ... It looks like we probably have to re-think a few of our workflows and procedures, and until/unless that happens, logical replication won't do what we want. Which means figuring out this 13-million-files problem becomes a very low priority for me. Unfortunately: it'd be nice to track it down and squash it... Thanks everyone, -- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
Вложения
В списке pgsql-general по дате отправления: