From: | Dimitri Maziuk <dmaziuk(at)bmrb(dot)wisc(dot)edu> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: logical replication snapshots |
Date: | 2018-07-27 22:04:50 |
Message-ID: | 5c10ced3-7e1a-d673-1da9-d45985bf37f5@bmrb.wisc.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2018-07-27 22:20:37 | Re: logical replication snapshots |
Previous Message | Adrian Klaver | 2018-07-27 17:21:56 | Re: Postgresql 10.4 installation issues on Ubuntu 14.05 |