On Thu, 11 Jul 2019, David Fetter wrote:

> On Thu, Jul 11, 2019 at 01:10:43PM -0400, steve at ssinger.info steve at ssinger.info wrote:
>> 14GB isn't very big.
>> Any idea what is happening?
>
> Nope, and that's why I wrote here.
>
>> Are there any locks on the table (on the origin or replica) that could be preventing this?
>
> Not that I can see.
>
>> What is in the slon log, for the slon for the replica.
>
> Nothing in sl_log_1 or sl_log_2 on the either the origin or the replica, nothing in
> /var/log/slony1/ on either the origin or the replica.

'nothing' in the log makes me think that your looking at the wrong log file, 
or logging isn't working.

I would expect to see something like the following when it starts to copy a 
table

INFO   copy_set 1 - omit=f - bool=0

Just before the copy starts

EDT CONFIG remoteWorkerThread_1: Begin COPY of table ......
(for each table)

It should go through with one of this for each table in the set. This 
indicates copying of that table is starting.

You might also see some indications that the remoteWorker is connecting to 
the origin database.
Ie
CONFIG remoteWorkerThread_1: connected to provider DB

Prior to the subscribe set being processed I would expect to still see

INFO   remoteWorkerThread_1: SYNC 5000000037 done in 0.001 seconds

type events in the log


>
>> Did the COPY start?
>
> How would I tell?
>
>> Did the replica get some data and then things hung?
>
> It did not get data. I have several other clusters running (different
> DBs, same hosts) without incident. It's just this one that's failing
> to do the initial sync.
>
> Best,
> David.
> -- 
> David Fetter <david(at)fetter(dot)org> http://fetter.org/
> Phone: +1 415 235 3778
>
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
>