<div dir="ltr"><div dir="ltr">On Tue, Jun 11, 2019 at 3:44 PM Tory M Blue &lt;<a href="mailto:tmblue@gmail.com">tmblue@gmail.com</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 11, 2019 at 12:26 PM Christopher Browne &lt;<a href="mailto:cbbrowne@afilias.info" target="_blank">cbbrowne@afilias.info</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 11, 2019 at 1:30 PM Tory M Blue &lt;<a href="mailto:tmblue@gmail.com" target="_blank">tmblue@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I&#39;m wondering if there is anything I can do to prevent what appears to be slony replication backup (not replicating) during a pg_dump. I&#39;m using a -N slonschema, so wondering if there is any other techniques to prevent slon replication delay during pg_dumps?<br></div></blockquote><div><br></div><div>Hmm.  I remember the &quot;big deal&quot; being to ensure that the Slony schema was left out, as that would definitely lead to locking that would cause replication to fall behind.</div><div><br></div><div>It&#39;s possible that something new has come along that would lock in a troublesome way.</div><div><br></div><div>I suggest that you take a look in pg_catalog.pg_locks to see what objects Slony is waiting on, thus, looking for:</div><div><br></div><div>  select * from pg_catalog.pg_locks where not granted;</div><div><br></div><div>Some further work needs to be done to trace that to exactly what objects are locked.<br></div></div></div></blockquote><div><br></div><div>Ya will take a look, I also thought that bypassing the slon schema would solve it but apparently not, we can have 2-10million count in the sl_log before it clears and it&#39;s apparent that the replication is not happening, so I&#39;ll poke around some more. Glad to see folks are still around :)</div></div></div></blockquote><div><br></div><div>Well, growth of sl_log during the backup is fine, and not an indication of anything untowards.  Given that you opened a transaction when pg_dump began, and that has not completed, that will lead to Slony not trimming anything out of sl_log during the backup.  That&#39;s normal, routine stuff.  Nothing&#39;s wrong (not on the basis of that, anyways).</div><div><br></div><div>On the origin node, you can query the view sl_status, which will show how far behind replication appears to be.  (The view is available on all nodes; it does not return terribly interesting results on nodes other than the origin.)</div><div><br></div><div>Here&#39;s an example of replication being very far behind:</div><div><br></div><div>usaorigin=# select * from _usa.sl_status limit 3;<br>-[ RECORD 1 ]-------------+------------------------------<br>st_origin                 | 1<br>st_received               | 3<br>st_last_event             | 5000002124<br>st_last_event_ts          | 2019-04-10 20:02:43.833414+00<br>st_last_received          | 5000002124<br>st_last_received_ts       | 2019-04-10 20:02:43.885806+00<br>st_last_received_event_ts | 2019-04-10 20:02:43.833414+00<br>st_lag_num_events         | 0<br>st_lag_time               | 62 days 20:23:14.029816<br>-[ RECORD 2 ]-------------+------------------------------<br>st_origin                 | 1<br>st_received               | 4<br>st_last_event             | 5000002124<br>st_last_event_ts          | 2019-04-10 20:02:43.833414+00<br>st_last_received          | 5000002122<br>st_last_received_ts       | 2019-04-10 20:02:33.870577+00<br>st_last_received_event_ts | 2019-04-10 20:02:23.76373+00<br>st_lag_num_events         | 2<br>st_lag_time               | 62 days 20:23:34.0995<br>-[ RECORD 3 ]-------------+------------------------------<br>st_origin                 | 1<br>st_received               | 5<br>st_last_event             | 5000002124<br>st_last_event_ts          | 2019-04-10 20:02:43.833414+00<br>st_last_received          | 5000002122<br>st_last_received_ts       | 2019-04-10 20:02:33.898605+00<br>st_last_received_event_ts | 2019-04-10 20:02:23.76373+00<br>st_lag_num_events         | 2<br>st_lag_time               | 62 days 20:23:34.0995<br></div><div><br></div><div>That is a replication cluster where I shut down slon processes back in April :-)</div><div><br></div><div>It&#39;s only behind by a few events, for the self-same reason :-)</div><div><br></div><div>If the last event received coincides with the time at which you started the pg_dump run, well, that sure sounds like a smoking gun.</div><div><br></div><div>If, on the other hand, SYNC events are being processed, just at slower speed than you&#39;d like, then perhaps the problem is that the I/O induced by pg_dump is delaying replication, and that&#39;s more a hardware problem than a software one.</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">And if replication is a few seconds behind, while the system is busy, as indicated by st_lag_time being a few seconds, then it&#39;s possible that there is no problem there.<br></div></div>