<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>Aus der Tiefe</title>
    <link>https://adminblog.math.fau.de/2015/10/06/index.rss/</link>
    <description>Meldungen des Rechenzentrums in der Cauerstrasse 11</description>
    <language>de</language>
    <docs>http://blogs.law.harvard.edu/tech/rss</docs>
    <generator>blosxom/2.1.2</generator>

  <item>
    <title></title>
    <pubDate>Tue, 06 Oct 2015 00:00:00 +0200</pubDate>
    <link>https://adminblog.math.fau.de/2015/10/06/index.rss/2015/10/06#TuesdayOctober6201521:14:34</link>
    <category>/bauerm</category>
    <guid isPermaLink="false">https://adminblog.math.fau.de/2015/10/06/index.rss/bauerm/TuesdayOctober6201521:14:34</guid>
    <description>&lt;pre&gt;
	Platte auf monitor mal wieder uebergelaufen, wegen Datenmasse von zabbix. In ~robauerm/bin liegt
	  ein aufraeumscript, das mit SELECT INTO, TRUNCATE, DROP TABLE, ALTER TABLE eine verkuerze
	  Version von history und history_uint macht und den Plattenplatz sicher freigibt.
	Um dem VACCUM vom Postgres eine Chance zu geben, kann man z.B. folgendes probieren:

	  CREATE OR REPLACE FUNCTION cleanup() RETURNS trigger AS $$
	   BEGIN  
	    DELETE FROM history WHERE clock &lt; ( (extract(epoch from now()))::int - 24*3600*7); 
	    RETURN NEW; 
	   END;
	   $$  LANGUAGE &apos;plpgsql&apos;;
	  CREATE TRIGGER cleanuphistory AFTER INSERT ON history EXECUTE PROCEDURE cleanup();

	In einer Demo-DB in unserem Postgres getestet, vernichtet die alten Eintraege bei jeden INSERT...

&lt;/pre&gt;</description>
  </item>
  </channel>
</rss>
