Hi I'm using pg_dump 9.6 to do the dumps.
I'm also pretty sure no data is being replicated until the end of the copy stdin as I was watching tcpdump output and I can see data from the orig master to the new master and no traffic between new master and the standby, pretty sure my replication is working as my other tables have replicated over. as for allow pg_dump to create copy stdin with specific number of rows - not sure what that is so hard / bad, if it was a option for somebody to use. For my situation its sounds like a really good idea. I'm dumping a single table into a new single table so constraint shouldn't be a problem. Guess I have to just let it rung to completion Thanks On 1 August 2017 at 06:59, Scott Marlowe <scott.marl...@gmail.com> wrote: > On Mon, Jul 31, 2017 at 2:31 AM, vinny <vi...@xs4all.nl> wrote: > > On 2017-07-31 11:02, Alex Samad wrote: > >> > >> Hi > >> > >> I am using pg_dump | psql to transfer data from my old 9.2 psql into a > >> 9.6 psql. > > Note that you should be doing pg_dump with 9.6's pg_dump, as it's > possible for 9.2's pg_dump to not know about a 9.6 feature. > > >> The new DB server is setup as master replicating to a hot standby > >> server. > >> > >> What I have noticed is that the rows don't get replicated over until > >> the copy from stdin is finished... hard to test when you have M+ lines > >> of rows. > > SNIP > > >> Is there a way to tell the master to replicate earlier > > > > I highly doubt it, because the master cannot know what to replicate until > > your transaction is ended with a COMMIT. If you end with ROLLBACK, > > or your last query is DELETE FROM (your_table>; > > then there isn't even anything to replicate at all... > > This is actually a visibility issue. All the new changes are > replicated to the slave, but just like on the master, other > connections can't see the change because it's not visible. The slave, > except for some small delay (seconds etc) is an exact replica of the > master. So even a delete at the end gets replicated. You just don't > see anything but possible table bloat to show for it. > > To prove this to oneself, start the copy, and get into another session > to the master. You don't see any rows there either until the commit > after the copy. >
