<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>The Pythian Blog &#187; bug</title>
	<atom:link href="http://www.pythian.com/news/tag/bug/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pythian.com/news</link>
	<description>News and views from Pythian DBAs</description>
	<lastBuildDate>Fri, 10 Feb 2012 09:54:45 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
		<item>
		<title>Ubuntu 9.04 (Jaunty Jackalope), vpnc, and resolvconf</title>
		<link>http://www.pythian.com/news/2931/ubuntu-904-jaunty-jackalope-vpnc-and-resolvconf/</link>
		<comments>http://www.pythian.com/news/2931/ubuntu-904-jaunty-jackalope-vpnc-and-resolvconf/#comments</comments>
		<pubDate>Thu, 18 Jun 2009 21:50:54 +0000</pubDate>
		<dc:creator>Brad Hudson, SA Team Lead</dc:creator>
				<category><![CDATA[SysAdmin]]></category>
		<category><![CDATA[/etc/resolv.conf]]></category>
		<category><![CDATA[bug]]></category>
		<category><![CDATA[DNS]]></category>
		<category><![CDATA[jaunty]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[resolvconf]]></category>
		<category><![CDATA[tun0]]></category>
		<category><![CDATA[Ubuntu]]></category>
		<category><![CDATA[vpnc]]></category>
		<category><![CDATA[workaround]]></category>

		<guid isPermaLink="false">http://www.pythian.com/news/?p=2931</guid>
		<description><![CDATA[The environment Ubuntu 9.04 Jaunty Jackalope vpnc 0.5.3 resolvconf 1.43 The problem Connecting to a cisco vpn device with vpnc on jaunty. If you use vpnc and vpnc-disconnect to bring the connection up and down, all works fine. If you leave the connection idle too long and are disconnected from the other end, the resolv.conf [...]]]></description>
		<wfw:commentRss>http://www.pythian.com/news/2931/ubuntu-904-jaunty-jackalope-vpnc-and-resolvconf/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>Bug When Compiling MySQL 5.1 From Source</title>
		<link>http://www.pythian.com/news/2874/bug-when-compiling-mysql-51-from-source/</link>
		<comments>http://www.pythian.com/news/2874/bug-when-compiling-mysql-51-from-source/#comments</comments>
		<pubDate>Wed, 17 Jun 2009 18:55:43 +0000</pubDate>
		<dc:creator>Gerry Narvaja</dc:creator>
				<category><![CDATA[Group Blog Posts]]></category>
		<category><![CDATA[bug]]></category>
		<category><![CDATA[compiling]]></category>
		<category><![CDATA[install]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[source code]]></category>
		<category><![CDATA[sphinx]]></category>
		<category><![CDATA[sphinxse]]></category>

		<guid isPermaLink="false">http://www.pythian.com/news/?p=2874</guid>
		<description><![CDATA[I just filed a very annoying bug when trying to compile with plugin engines using the 5.1.xx source tarball. Description I am trying to test SphinxSE as a plugin instead of getting it statically linked and came across an annoying bug. When using the configure --with-plugins option only once, the engine is statically linked. When [...]]]></description>
		<wfw:commentRss>http://www.pythian.com/news/2874/bug-when-compiling-mysql-51-from-source/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Turn Off db_cache_advice To Avoid Latch Contention Bugs</title>
		<link>http://www.pythian.com/news/2838/turn-off-db_cache_advice-to-avoid-latch-contention-bugs/</link>
		<comments>http://www.pythian.com/news/2838/turn-off-db_cache_advice-to-avoid-latch-contention-bugs/#comments</comments>
		<pubDate>Tue, 09 Jun 2009 21:23:59 +0000</pubDate>
		<dc:creator>Don Seiler</dc:creator>
				<category><![CDATA[Oracle]]></category>
		<category><![CDATA[bug]]></category>
		<category><![CDATA[contention]]></category>
		<category><![CDATA[latch]]></category>

		<guid isPermaLink="false">http://www.pythian.com/news/?p=2838</guid>
		<description><![CDATA[A couple of weeks ago, we noticed some timeouts in some of our standard Oracle RDBMS health check scripts on a new instance. I had just migrated this instance to bigger, better, badder hardware and so it had been given more SGA to use, namely a bigger buffer cache. The software version was still Oracle [...]]]></description>
		<wfw:commentRss>http://www.pythian.com/news/2838/turn-off-db_cache_advice-to-avoid-latch-contention-bugs/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>ORA-16069?  You May Need A New Standby Controlfile</title>
		<link>http://www.pythian.com/news/1902/ora-16069-new-standby-controlfile/</link>
		<comments>http://www.pythian.com/news/1902/ora-16069-new-standby-controlfile/#comments</comments>
		<pubDate>Wed, 15 Apr 2009 16:00:34 +0000</pubDate>
		<dc:creator>Don Seiler</dc:creator>
				<category><![CDATA[Oracle]]></category>
		<category><![CDATA[4048687]]></category>
		<category><![CDATA[bug]]></category>
		<category><![CDATA[controlfile]]></category>
		<category><![CDATA[database]]></category>
		<category><![CDATA[ORA-16069]]></category>
		<category><![CDATA[standby]]></category>

		<guid isPermaLink="false">http://www.pythian.com/news/?p=1902</guid>
		<description><![CDATA[On a recent Monday, I had to perform an emergency Oracle standby switchover for a client whose primary instance host had mysteriously rebooted itself over the previous day. Confidence in that host was, understandably, shaken. The Oracle Data Guard configuration is a 3-instance setup using Data Guard Broker: one primary, we&#8217;ll call it OraA, feeding [...]]]></description>
		<wfw:commentRss>http://www.pythian.com/news/1902/ora-16069-new-standby-controlfile/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>InnoDB Hot Backup Utility Bug</title>
		<link>http://www.pythian.com/news/1500/innodb-hot-backup-utility-bug/</link>
		<comments>http://www.pythian.com/news/1500/innodb-hot-backup-utility-bug/#comments</comments>
		<pubDate>Tue, 24 Feb 2009 17:51:47 +0000</pubDate>
		<dc:creator>Singer Wang</dc:creator>
				<category><![CDATA[MySQL]]></category>
		<category><![CDATA[backups]]></category>
		<category><![CDATA[bug]]></category>
		<category><![CDATA[InnoDB]]></category>
		<category><![CDATA[innodb hot backup]]></category>

		<guid isPermaLink="false">http://www.pythian.com/blogs/1500/innodb-hot-backup-utility-bug</guid>
		<description><![CDATA[If you are using InnoDB Hot Backup utility and the innobackup.pl wrapper script, be very careful if you are not running backups under the system mysql user. There is a bug which causes InnoDB Hot Backup to sometimes report a successful backup when it actually failed. The last few dozen lines of the output was [...]]]></description>
		<wfw:commentRss>http://www.pythian.com/news/1500/innodb-hot-backup-utility-bug/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

