<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Hi Jan,</span></div><div><br><span></span></div><div><span>Thanks for sharing these information.</span></div><div><br><span></span></div><div><span>Do you think it is worth waiting that replication could catch up properly.</span></div><div><br><span></span></div><div><span>Yesterday while this issue was occuring<br></span></div><div><span><br></span></div><div><span>- I stopped replication on all nodes and</span></div><div><span>- I restarted the PostgreSQL server on the master</span></div><div><span>- I restaerted Slony processes on all nodes.</span></div><div><br><span></span></div><div><span>Then I guess that my issue is related to "</span>A replica that is far behind."</div><div><br><span></span></div><span>Indeed Slony processes are redirected localy on the disk (/ partition) with log_level = 1. I don't used any
 log rotate mechanism<br><br></span><div><span>There
 is free disk space (50GB) if need on /var/database partition or do you 
advise me to stop replication and rebuidl replication for scratch??</span></div>
<div><br>
  <span></span></div>
<div><span>This is the last solution I have but I wanted to know if it is worth waiting. </span></div><div><br></div>  <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1">  <b><span style="font-weight:bold;">De&nbsp;:</span></b> Jan Wieck &lt;JanWieck@Yahoo.com&gt;<br> <b><span style="font-weight: bold;">À&nbsp;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&gt; <br><b><span style="font-weight: bold;">Cc&nbsp;:</span></b> Slony Hackers &lt;slony1-hackers@lists.slony.info&gt; <br> <b><span style="font-weight: bold;">Envoyé le :</span></b> Jeudi 26 juillet 2012 14h22<br> <b><span style="font-weight: bold;">Objet&nbsp;:</span></b> Re: [Slony1-hackers] sl_log_1 doesn't stop to grow<br> </font> </div> <br>On 7/26/2012 7:54 AM, David TECHER wrote:<br>&gt; Hi<br>&gt; <br>&gt;
 Yesterday on our production server, the / partition was fully populated.<br>&gt; <br>&gt; - Slony 1.2.22 is running on /<br>&gt; - our databases files are locate at /var/database<br>&gt; - PostgreSQL binaries are located into /opt/PostgresPlus/8.3R2AS/ inside<br>&gt; of / partition<br>&gt; <br>&gt; df -h / /var/database/<br>&gt; Filesystem&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Size&nbsp; Used Avail Use% Mounted on<br>&gt; /dev/mapper/VG1-root&nbsp;  18G&nbsp; 2.1G&nbsp;  16G&nbsp; 12% /<br>&gt; /dev/sdf1&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  253G&nbsp; 176G&nbsp;  78G&nbsp; 70% /var/database<br>&gt; <br>&gt; Quick workaround was to clean up /tmp (inside of /)<br>&gt; <br>&gt; However a couple hours ago, while I was trying to build a new set<br>&gt; replication hangs.<br>&gt; <br>&gt; I discovered that sl_log_1 table doesn't stop to growing. (more than<br>&gt; 30GB size).<br><br>That can have two possible reasons.<br><br>1) A long running
 transaction.<br><br>2) A replica that is far behind.<br><br>Both situations prevent the log switching from sl_log_2 to sl_log_1 to complete. The long running transaction may still write log rows to sl_log_2 and the far behind replica would still need rows that are in sl_log_2. In both cases Slony cannot truncate sl_log_2 at this moment and therefore cannot initiate another log switch.<br><br>Note that under 1.2.x this is a serious issue. 1.2.x misses an optimization in the log select query which causes the query planner to not generate a lower index scan key. As your replicas advance to the end of those 30 GB with their SYNC processing, they will scan the whole thing over and over.<br><br>&gt; <br>&gt; I would like to know if there is any temporary files generated by Slony<br>&gt; which may explains why this table doesn't stop to grow.<br><br>Slony does not create any temporary files. Unless you are using archive shipping, the only thing that comes to
 mind is the stdout, eventually on an unreasonably high debug level, redirected into some file without any log rotate mechanism.<br><br>&gt; <br>&gt; I don't know if the two issues are linked.<br><br>Probably not.<br><br><br>Jan<br><br>-- Anyone who trades liberty for security deserves neither<br>liberty nor security. -- Benjamin Franklin<br><br><br> </div> </div>  </div></body></html>