<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Problème de verrou?</title>
	<atom:link href="http://www.dbnewz.com/2007/08/28/probleme-de-verrou/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.dbnewz.com/2007/08/28/probleme-de-verrou/</link>
	<description>le blog français sur les SGBD - MySQL, Oracle et plus...</description>
	<pubDate>Sat, 22 Nov 2008 03:42:07 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: greg</title>
		<link>http://www.dbnewz.com/2007/08/28/probleme-de-verrou/#comment-15</link>
		<dc:creator>greg</dc:creator>
		<pubDate>Wed, 05 Sep 2007 09:13:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbnewz.com/2007-08/25-probleme-de-verrou.htm#comment-15</guid>
		<description>Testé avec succès sur postgrsql 8.1 quelque soit le nombre d'enregistrements,
ils ont par contre un autre bug  (extrait de la doc):

BEGIN;
SELECT * FROM mytable WHERE key = 1 FOR UPDATE;
SAVEPOINT s;
UPDATE mytable SET ... WHERE key = 1;
ROLLBACK TO s;

Le «rollback to s» va quand même unlocker les rows de la table du précédent SELECT.</description>
		<content:encoded><![CDATA[<p>Testé avec succès sur postgrsql 8.1 quelque soit le nombre d&#8217;enregistrements,<br />
ils ont par contre un autre bug  (extrait de la doc):</p>
<p>BEGIN;<br />
SELECT * FROM mytable WHERE key = 1 FOR UPDATE;<br />
SAVEPOINT s;<br />
UPDATE mytable SET &#8230; WHERE key = 1;<br />
ROLLBACK TO s;</p>
<p>Le «rollback to s» va quand même unlocker les rows de la table du précédent SELECT.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pébé</title>
		<link>http://www.dbnewz.com/2007/08/28/probleme-de-verrou/#comment-14</link>
		<dc:creator>pébé</dc:creator>
		<pubDate>Wed, 05 Sep 2007 08:35:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbnewz.com/2007-08/25-probleme-de-verrou.htm#comment-14</guid>
		<description>Salut Greg, 
je l'ai testé sur la version utilisé par la personne en question, soit MySQL 4.1.
Néanmoins, je ne pense pas que MySQL ai modifié le fonctionnement de  l'optimiser. Si la table est petite, il va toujours avoir tendance à faire un FULL TABLE scan que de s'embêter avec des index.</description>
		<content:encoded><![CDATA[<p>Salut Greg,<br />
je l&#8217;ai testé sur la version utilisé par la personne en question, soit MySQL 4.1.<br />
Néanmoins, je ne pense pas que MySQL ai modifié le fonctionnement de  l&#8217;optimiser. Si la table est petite, il va toujours avoir tendance à faire un FULL TABLE scan que de s&#8217;embêter avec des index.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: greg</title>
		<link>http://www.dbnewz.com/2007/08/28/probleme-de-verrou/#comment-13</link>
		<dc:creator>greg</dc:creator>
		<pubDate>Wed, 05 Sep 2007 08:26:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.dbnewz.com/2007-08/25-probleme-de-verrou.htm#comment-13</guid>
		<description>Comme je sais que tout change entre chaque version de MySQL, peut on savoir sur quelle version cette démonstration est valable ?</description>
		<content:encoded><![CDATA[<p>Comme je sais que tout change entre chaque version de MySQL, peut on savoir sur quelle version cette démonstration est valable ?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
