gleu's blog

Mise à jour : plusieurs corrections de Thomas, Merci !

Désolé pour l'interruption des programmes, j'ai été plutôt occupé ces derniers temps.

Avant tout, n'oubliez pas de récupérer la mise à jour des sources et à compiler le tout.

On en était à vouloir réellement implémenter le déplacement des fichiers. Malheureusement, c'est peut-être encore un peu trop tôt pour cela. Avant de déplacer les fichiers, il faut d'abord savoir quels fichiers déplacer. Et avant cela, il faut aussi savoir si on a le droit de le faire.

Commençons par les droits. Il existe une autre fonction qui touche à tous les fichiers : celle de suppression d'une base de données. La fonction se trouve là-aussi dans le fichier backend/commands/dbcommands.c, elle s'appelle dropdb. Le mieux est de la dupliquer et de renommer la nouvelle en movedb. L'argument de cette nouvelle fonction est le nom de la base. Il faut aussi supprimer certains des tests inutiles dans notre cas : celui sur les bases de données modèles, celui qui empêche la suppression de la base de données où l'utilisateur est connecté. D'autres appels de fonctions sont aussi à supprimer car ils n'ont rien à voir avec notre fonction. Voici le résultat de l'élagage :

 /*
  * ALTER DATABASE SET TABLESPACE
  */
 void
 movedb(const char *dbname)
 {
 	Oid			db_id;
 	bool		db_istemplate;
 	Relation	pgdbrel;
 	int			notherbackends;
 	int			npreparedxacts;
 
 	/*
 	 * Look up the target database's OID, and get exclusive lock on it. We
 	 * need this to ensure that no new backend starts up in the target
 	 * database while we are moving it, and that no one is
 	 * using it as a CREATE DATABASE template or trying to delete it for
 	 * themselves.
 	 */
 	pgdbrel = heap_open(DatabaseRelationId, RowExclusiveLock);
 
 	if (!get_db_info(dbname, AccessExclusiveLock, &db_id, NULL, NULL,
 					 &db_istemplate, NULL, NULL, NULL, NULL, NULL, NULL))
 	{
 		ereport(ERROR,
 				(errcode(ERRCODE_UNDEFINED_DATABASE),
 				 errmsg("database \"%s\" does not exist", dbname)));
 	}
 
 	/*
 	 * Permission checks
 	 */
 	if (!pg_database_ownercheck(db_id, GetUserId()))
 		aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_DATABASE,
 					   dbname);
 
       /* Obviously can't move the tables of another database than my own */
       if (db_id != MyDatabaseId)
           ereport(ERROR,
                  (errcode(ERRCODE_OBJECT_IN_USE),
                    errmsg("cannot move the relations of another database than the currently open one")));  
 	/*
 	 * Check for other backends in the target database.  (Because we hold the
 	 * database lock, no new ones can start after this.)
 	 *
 	 * As in CREATE DATABASE, check this after other error conditions.
 	 */
 	CountOtherDBBackends(db_id, &notherbackends, &npreparedxacts);
 	if (notherbackends > 1 || npreparedxacts > 0)
 		ereport(ERROR,
 				(errcode(ERRCODE_OBJECT_IN_USE),
 				 errmsg("database \"%s\" is being accessed by other users",
 						dbname),
 				 errdetail_busy_db(notherbackends, npreparedxacts)));
 
 	/*
 	 * Force a checkpoint to make sure the bgwriter has received the message
 	 * sent by ForgetDatabaseFsyncRequests. On Windows, this also ensures that
 	 * the bgwriter doesn't hold any open files, which would cause rmdir() to
 	 * fail.
 	 */
 	RequestCheckpoint(CHECKPOINT_IMMEDIATE | CHECKPOINT_FORCE | CHECKPOINT_WAIT);
 
 	/*
 	 * Close pg_database, but keep lock till commit (this is important to
 	 * prevent any risk of deadlock failure while updating flat file)
 	 */
 	heap_close(pgdbrel, NoLock);
 
 	/*
 	 * Set flag to update flat database file at commit.  Note: this also
 	 * forces synchronous commit, which minimizes the window between removal
 	 * of the database files and commital of the transaction. If we crash
 	 * before committing, we'll have a DB that's gone on disk but still there
 	 * according to pg_database, which is not good.
 	 */
 	database_file_update_needed();
 }

Nous devons déclarer cette fonction dans l'en-tête. Ce fichier se trouve dans le répertoire src/include/commands et se nomme dbcommands.h. Il faut ajouter cette ligne de déclaration :

 extern void movedb(const char *dbname);

Maintenant, il faut appeler cette fonction. Pour cela, retrouvons le message qu'on envoyait dans le log (à savoir, « set tablespace ! »). Il suffit d'ajouter l'appel à la fonction. J'en profite aussi pour changer le message et obtenir quelque chose de plus intéressant, ce qui me donne le résultat suivant :

 else if (strcmp(defel->defname, "tablespace") == 0)
 {
   elog(NOTICE,
     "alter tablespace %s set tablespace %s!", stmt->dbname, strVal(defel->arg));
   movedb(stmt->dbname);
 }

Après toute ces modifications, compilons pour tester le résultat. Et enfin testons. Je connecte un psql sur db1. Puis je lance un autre psql sur la base postgres. J'exécute le ALTER DATABASE à partir de ce deuxième psql et j'obtiens :

 postgres=# alter database db1 tablespace mon_espace_de_stockage;
 NOTICE:  alter tablespace db1 set tablespace mon_espace_de_stockage!
 ERROR:  database "db1" is being accessed by other users
 DETAIL:  There are 1 other session(s) using the database.

La fonction a bien détecté l'autre client connecté et a empêché la suite des opérations. Déconnectons cet utilisateur et tentons de nouveau l'opération :

 postgres=# alter database db1 tablespace mon_espace_de_stockage;FATAL:  role "postgres" does not exist
 NOTICE:  alter tablespace db1 set tablespace mon_espace_de_stockage!
 ALTER DATABASE

Ça passe sans problème. Je vous laisse tester le reste. Je préfère passer à la suite, à savoir récupérer la liste des tables. Un petit soucis pointe son nez. Pour récupérer la liste des tables, je vais exécuter une requête sur pg_class. Or cette dernière ne va me donner des informations que sur la base où je suis connecté. Il faut donc modifier les tests pour s'assurer qu'il n'y a qu'un seul client connecté et que ce client est moi.

Ceci fait, la récupération des tables de la base devient notre priorité. Pour cela, nous allons utiliser la fonction heap_beginscan qui permet de réaliser un parcours d'une table. Elle demande plusieurs arguments dont la table à parcourir et un filtre optionnel. La table doit d'abord est ouverte, ce qui se fait avec la fonction heap_open, qui prend deux arguments, à savoir le nom de la table et le type de verrou). Quant au filtre, nous voulons récupéré toutes les lignes représentant des relations (constante Anum_pg_class_relkind). Ceci fait, nous avons donc ouvert la table, initié un parcours de table. Reste à récupérer les valeurs. La fonction heap_getnext va nous aider pour cela. Il nous suffit de l'emballer dans une boucle et le tour est joué. Tout ceci nous donne le code suivant :

 /* Process all plain relations listed in pg_class */
 ScanKeyInit(&key,
   Anum_pg_class_relkind,
   BTEqualStrategyNumber, F_CHAREQ,
   CharGetDatum(RELKIND_RELATION));
 
 pgclass = heap_open(RelationRelationId, AccessShareLock);
 
 scan = heap_beginscan(pgclass, SnapshotNow, 1, &key);
 
 while ( ( tuple = heap_getnext(scan, ForwardScanDirection ) ) != NULL)
 {
   elog(NOTICE, "relation %s", NameStr->relname));
 }
 
 heap_endscan(scan);
 heap_close(pgclass, AccessShareLock);

Reprenons notre cycle habituel : compilation, installation, tests...

 db1=# alter database db1 tablespace mon_espace_de_stockage;
 NOTICE:  alter tablespace db1 set tablespace mon_espace_de_stockage!
 NOTICE:  relation pg_type                                           
 NOTICE:  relation sql_implementation_info                           
 NOTICE:  relation sql_languages                                     
 [... coupé parce qu'inintéressant ...]
 NOTICE:  relation pg_namespace
 NOTICE:  relation pg_conversion
 NOTICE:  relation pg_depend
 NOTICE:  relation t1
 ALTER DATABASE

Et voilà, c'est parfait. Il ne reste plus qu'à donner l'ordre de déplacer la table.

Je reviens tout juste de Toulouse. La première édition de PGDay France vient de se terminer. L'expérience fut bonne. J'ai tout particulièrement apprécié la prestation de Guillaume Smet. Mais plutôt que de partir moi-aussi dans la description de toutes les conférences, je vous conseille de lire le billet de Thomas Petazzoni. Bien que peu intéressé par le domaine des bases de données, il a participé fréquemment aux discussions de préparation de cette journée en tant que membre du LUG local. Il a aussi passé sa journée à filmer toutes les conférences, ce qui nous permettra de mettre rapidement en ligne celles-ci pour ceux qui n'ont pas pu venir. Bref, il était là et ses commentaires sur la journée rejoignent fortement mes impressions.

J'ai pris un certain nombre de photos que vous trouverez ici dans un premier temps. Elles sont brutes, aucune retouche, y compris pour les yeux rouges, ni même une simple suppression des photos floues. Je suis trop fatigué pour m'en occuper ce soir. Si certains ne souhaitent pas apparaître, qu'ils me laissent un simple commentaire et je supprimerais la photo du site.

Dernier point, je tiens à remercier toutes les personnes qui ont participé à la mise en place de PGDayFr 2008, et notamment Jean-Christophe Arnu, qui, par sa proximité géographique, a réalisé de très nombreuses démarches pour que cet événement ait lieu. (Et je ne me remercie pas vu que je n'ai pratiquement pas participé... préparer ce genre d'événements n'est pas quelque chose qui me motive suffisament).

Je viens tout juste de placer cet article sur dalibo.org, initialement paru sous le numéro 106 de GNU/Linux Magazine France, et maintenant disponible sous licence Creative Commons.

J'ai aussi envoyé mon tout dernier article à Denis Bodor, le rédacteur-en-chef du magazine. J'attends son verdict Pour infos, cela porte sur la recherche plein texte, et plus précisément sur la configuration de cette fonctionnalité.

Pour les suivants, j'avoue que je commence à être un peu à court d'idées... si quelqu'un a une proposition, je suis preneur Dans les articles possibles, j'ai :

• nouveautés SQL et PL/pgsql en 8.3 ;
• gestion des processus avec PostgreSQL ;
• nouveautés sur les performances.

Le premier me plaît moyen mais il permettrait de faire un article simple avec des nouveautés, donc dans l'esprit de ce que je fais depuis le premier article. Le second me plaît plus, on met beaucoup plus les mains dans le cambouis. Le dernier me plaît beaucoup aussi mais va demander beaucoup plus de travail que ce que je peux faire actuellement.

Bref, une autre idée serait la bienvenue...

Dur matin aujourd'hui... mal réveillé, pas en super forme après le déménagement de ce week-end... Pfiou que de mails en attente, et de billets de blogs non lus. C'est vrai que ça fait cinq jours que je suis à fond dans le boulot et le déménagement. Bref.

Je viens de lire un billet qui m'a fait beaucoup plaisir. Leo Hsu et Regina Obe (les auteurs du Postgres Online Journal) ont testé la version de développement de pgAdmin (la 1.9) et viennent de publier leurs impressions. En fait, ils citent les cinq nouvelles fonctionnalités qui les ont le plus marqué. En tout premier, le support de FTS. J'en ai déjà (trop ?) longuement parlé. Ensuite le concepteur de requêtes graphiques. Enfin, le dimensionnement modifiable des fenêtres, la gestion de l'héritage des tables et le champ SQL modifiable.

Autrement dit, sur les cinq fonctionnalités qu'ils ont choisi de mettre en avant, quatre ont été codées par moi Hmmm... vous ne pouvez pas vous plaindre, je vous avais prévenu dans le titre

continuons à améliorer l'interface

Je n'ai pas trop le temps, donc on va faire deux petites modifs rapides : ajouter l'aide dans psql et gérer la complétion automatique toujours dans psql.

Je laisse de côté les étapes de récupération des sources mises à jour (cvs -q update -d), la compilation/installation (make && make install), la possible ré-initialisation du cluster (j'en ai encore eu besoin... les développeurs bossent beaucoup ces temps-ci ), etc.

Testons la méta-commande \h sur la commande ALTER DATABASE :

guillaume@laptop$ psql postgres
psql (8.4devel)
Type "help" for help.

postgres=# \h alter database
Command:     ALTER DATABASE
Description: change a database
Syntax:
ALTER DATABASE name [ [ WITH ] option [ ... ] ]

where option can be:

    CONNECTION LIMIT connlimit

ALTER DATABASE name RENAME TO newname

ALTER DATABASE name OWNER TO new_owner

ALTER DATABASE name SET configuration_parameter { TO | = } { value | DEFAULT }
ALTER DATABASE name SET configuration_parameter FROM CURRENT
ALTER DATABASE name RESET configuration_parameter
ALTER DATABASE name RESET ALL

Il manque notre option. Le fichier à modifier, on l'a déjà aperçu dans un épisode précédent, est src/bin/psql/sql_help.h. On aperçoit dans les toutes premières lignes :

* *** Do not change this file by hand. It is automatically
* *** generated from the DocBook documentation.

Ah, dommage. Bon, on va quand même le modifier juste pour la forme

En lisant rapidement ce fichier, on arrive à la ligne 36 qui indique ceci :

    { "ALTER DATABASE",
      N_("change a database"),
      N_("ALTER DATABASE name [ WITH option ... ]\n\nwhere option can be:\n\n    CONNECTION LIMIT connlimit\n\nALTER DATABASE name RENAME TO newname\n\nALTER DATABASE name OWNER TO new_owner\n\nALTER DATABASE name SET configuration_parameter { TO | = } { value | DEFAULT }\nALTER DATABASE name SET configuration_parameter FROM CURRENT\nALTER DATABASE name RESET configuration_parameter\nALTER DATABASE name RESET ALL") },

Il suffit de modifier la troisième ligne en ajoutant le texte suivant après le mot connlimit : \n TABLESPACE tablespace_name. Après avoir modifié le fichier, il nous reste plus qu'à compiler et tester :

guillaume@laptop$ make && make install
[... coupé ...]
make1: quittant le répertoire « /home/guillaume/postgresql_src/pgsql/config »
PostgreSQL installation complete.
guillaume@laptop$ psql postgres
psql (8.4devel)
Type "help" for help.

postgres=# \h alter database
Command:     ALTER DATABASE
Description: change a database
Syntax:
ALTER DATABASE name [ [ WITH ] option [ ... ] ]

where option can be:

    CONNECTION LIMIT connlimit
    TABLESPACE tablespace_name

ALTER DATABASE name RENAME TO newname

ALTER DATABASE name OWNER TO new_owner

ALTER DATABASE name SET configuration_parameter { TO | = } { value | DEFAULT }
ALTER DATABASE name SET configuration_parameter FROM CURRENT
ALTER DATABASE name RESET configuration_parameter
ALTER DATABASE name RESET ALL

Yes ! ça fonctionne mais pas bien compliqué en fait.

Maintenant, la gestion de la complétion automatique. Actuellement, on a ceci :

guillaume@laptop$ psql postgres
psql (8.4devel)
Type "help" for help.

postgres=# alter DATABASE guillaume<tab><tab>
CONNECTION LIMIT  OWNER TO          RENAME TO         RESET             SET
postgres=# alter DATABASE guillaume

<tab> étant à remplacer par une tabulation. On voit là-aussi que le mot clé TABLESPACE ne s'y trouve pas... allez hop, on se remonte les manches. Là-aussi, on connaît déjà le fichier, il s'agit de src/bin/psql/tab-complete.c. On peut chercher ALTER DATABASE pour trouver à la première occurence cette partie :

	/* ALTER DATABASE <name> */
	else if (pg_strcasecmp(prev3_wd, "ALTER") == 0 &&
			 pg_strcasecmp(prev2_wd, "DATABASE") == 0)
	{
		static const char *const list_ALTERDATABASE =
		{"RESET", "SET", "OWNER TO", "RENAME TO", "CONNECTION LIMIT", NULL};

		COMPLETE_WITH_LIST(list_ALTERDATABASE);
	}

Les options semblent être toutes dans la variable list_ALTERDATABASE. Modifions-la pour ajouter l'option TABLESPACE. On compile de nouveau, et on teste :

guillaume@laptop$ psql postgres
psql (8.4devel)
Type "help" for help.

postgres=# alter database guillaume<tab><tab>
CONNECTION LIMIT  OWNER TO          RENAME TO         RESET             SET               TABLESPACE
postgres=# alter database guillaume

Ça fonctionne \o/

Bref, pas grand chose de nouveau, mais il fallait de toute façon le faire. On fera plus passionnant la prochaine fois.

Au fait, au dernier numéro, j'ai ajouté un fichier patch au billet sans expliquer comment je l'ai fait. C'est très simple, il suffit d'exécuter la commande suivante :

guillaume@laptop$ cvs diff > ~/tablespace2.patch

Le fichier obtenu correspond à celui en pièce jointe de ce fichier. Vous pouvez appliquer ce patch en vous plaçant dans le répertoire des sources et en exécutant la commande suivante :

guillaume@laptop$ patch -Np0 < chemin/vers/tablespace2.patch

un peu de recherche

Nous venons de voir qu'une table est un fichier dont le nom dépend du relfilenode de la table et qui se trouve dans le sous-répertoire correspondant à l'OID de la base de données, lui même appartenant au répertoire du tablespace.

Déplacer une table d'un tablespace à un autre doit simplement revenir à faire un mv du fichier vers le nouveau tablespace. Vérifions cela.

Avant toute action sur les sources, commençons par les mettre à jour :

guillaume@laptop$ cd postgresql_src/pgsql/
guillaume@laptop$ cvs -q update -d
[... coupé parce que trop long ...]
P src/timezone/data/leapseconds
P src/timezone/data/northamerica
P src/timezone/data/southamerica
P src/timezone/data/zone.tab
P src/tools/msvc/Install.pm

OK. Plaçons-nous maintenant dans le répertoire src où se concentrent tous les fichiers sources de PostgreSQL (pour ceux qui connaissent le répertoire contrib, il contient bien des sources, mais ces sources ne font pas partis du moteur).

guillaume@laptop$ cd src

Recherchons toutes les occurences de « set tablespace », mais filtrons les fichiers intermédiaires de compilation (suffixe .o), les fichiers de traduction (suffixe .po) et les fichiers binaires.

guillaume@laptop$ grep -ri "set tablespace" * | grep -v "\.po" | grep -v "\.o" | grep -v "Fichier binaire"
backend/parser/gram.y:                  /* ALTER TABLE <name> SET TABLESPACE <tablespacename> */
backend/parser/gram.y:                  | SET TABLESPACE name
backend/commands/tablecmds.c:           case AT_SetTableSpace:  /* SET TABLESPACE */
backend/commands/tablecmds.c:           case AT_SetTableSpace:  /* SET TABLESPACE */
backend/commands/tablecmds.c:                    * If we had SET TABLESPACE but no reason to reconstruct tuples,
backend/commands/tablecmds.c: * ALTER TABLE SET TABLESPACE
backend/commands/tablecmds.c:                            errmsg("cannot have multiple SET TABLESPACE subcommands")));
backend/commands/tablecmds.c: * Execute ALTER TABLE SET TABLESPACE for cases where there is no tuple
bin/psql/sql_help.h:      N_("ALTER INDEX name RENAME TO new_name\nALTER INDEX name SET TABLESPACE tablespace_name\nALTER INDEX name SET ( storage_parameter = value , ... )\nALTER INDEX name RESET ( storage_parameter , ... )") },
bin/psql/sql_help.h:      N_("ALTER TABLE ONLY name *\n    action , ...\nALTER TABLE ONLY name *\n RENAME COLUMN column TO new_column\nALTER TABLE name\n    RENAME TO new_name\nALTER TABLE name\n    SET SCHEMA new_schema\n\nwhere action is one of:\n\n    ADD COLUMN column type column_constraint [ ... ]\n    DROP COLUMN column  RESTRICT \n    ALTER COLUMN column TYPE type USING expression\n    ALTER COLUMN column SET DEFAULT expression\n    ALTER COLUMN column DROP DEFAULT\n    ALTER COLUMN column { SET | DROP } NOT NULL\n ALTER COLUMN column SET STATISTICS integer\n    ALTER COLUMN column SET STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN }\n    ADD table_constraint\n    DROP CONSTRAINT constraint_name  RESTRICT \n    DISABLE TRIGGER  trigger_name \n    ENABLE TRIGGER  trigger_name \n    ENABLE REPLICA TRIGGER trigger_name\n ENABLE ALWAYS TRIGGER trigger_name\n    DISABLE RULE rewrite_rule_name\n    ENABLE RULE rewrite_rule_name\n    ENABLE REPLICA RULE rewrite_rule_name\n    ENABLE ALWAYS RULE rewrite_rule_name\n    CLUSTER ON index_name\n    SET WITHOUT CLUSTER\n    SET WITHOUT OIDS\n    SET ( storage_parameter = value , ... )\n    RESET ( storage_parameter , ... )\n INHERIT parent_table\n    NO INHERIT parent_table\n    OWNER TO new_owner\n    SET TABLESPACE new_tablespace") },
bin/psql/tab-complete.c:                {"SET TABLESPACE", "OWNER TO", "RENAME TO", "SET", "RESET", NULL};
bin/psql/tab-complete.c:        /* If we have TABLE <sth> SET TABLESPACE provide a list of tablespaces */
include/nodes/parsenodes.h:     AT_SetTableSpace,                       /* SET TABLESPACE */
interfaces/ecpg/preproc/preproc.y:              /* ALTER <name> SET TABLESPACE <tablespacename> */
interfaces/ecpg/preproc/preproc.y:              | SET TABLESPACE name
interfaces/ecpg/preproc/preproc.y:                      { $$ = cat2_str(make_str("set tablespace"), $3); }
interfaces/ecpg/preproc/preproc.c:    { (yyval.str) = cat2_str(make_str("set tablespace"), (yyvsp(3) - (3).str)); ;}
test/regress/input/tablespace.source:ALTER TABLE testschema.atable SET TABLESPACE testspace;
test/regress/input/tablespace.source:ALTER INDEX testschema.anindex SET TABLESPACE testspace;
test/regress/output/tablespace.source:ALTER TABLE testschema.atable SET TABLESPACE testspace;
test/regress/output/tablespace.source:ALTER INDEX testschema.anindex SET TABLESPACE testspace;

Les deux premières lignes concernent un fichier nommé gram.y. Le suffixe .y indique qu'il s'agit d'un fichier bison. Bison est un outil permettant de créer facilement un langage (pour les anciens Unixiens, Bison est la version GNU de yacc). C'est d'ailleurs ce fichier qu'il nous faudra modifier pour ajouter notre variante à l'instruction « ALTER TABLE ». Le fichier tablecmds.c a l'air de s'occuper de l'exécution concrète des commandes sur les tables. Son emplacement est d'ailleurs significatif. Le répertoire backends contient tous les sources du serveur, le sous-répertoire commands tous les sources concernant l'exécution des commandes SQL. Le fichier sql_help.h semble contenir l'aide proposée par psql via la commande \\h. Son emplacement est significatif là-aussi. Le répertoire bin contient tous les sources des outils binaires de PostgreSQL (psql, initdb, pg_dump, etc.). Le nom du fichier bin/psql/tab-complete.c nous donne une indication sur son utilité : il s'agit des sources pour la gestion de la complétion automatique dans psql. Quant au reste des fichiers, ils nous intéressent peu. Cela touche à ECPG et aux tests de régression. Beurk

Bref, le fichier qui nous intéresse le plus actuellement, c'est tablecmds.h. Ouvrons-le et recherchons la première occurence de « SET TABLESPACE ».

La première occurence correspond au début d'une instruction case :

case AT_SetTableSpace:	/* SET TABLESPACE */
  ATSimplePermissionsRelationOrIndex(rel);
  /* This command never recurses */
  ATPrepSetTableSpace(tab, rel, cmd->name);
  pass = AT_PASS_MISC;	/* doesn't actually matter */
  break;

Deux fonctions sont appelées. D'après leur nom, on imagine facilement que la première va vérifier les droits de la table ou de l'index, et que la second prépare l'exécution du « SET TABLESPACE ». Si on regarde dans quelle fonction se trouve ces instructions (simplement en remontant un peu), on trouve l'en-tête suivant :

/*
 * ATPrepCmd
 *
 * Traffic cop for ALTER TABLE Phase 1 operations, including simple
 * recursion and permission checks.
 *
 * Caller must have acquired AccessExclusiveLock on relation already.
 * This lock should be held until commit.
 */

Cette fonction traite la phase 1 de l'instruction « ALTER TABLE », qui laisse penser qu'il y a d'autres phases et que cette phase 1 est la phase préparatoire.

Bon, deuxième occurence :

case AT_SetTableSpace:	/* SET TABLESPACE */
  /*
   * Nothing to do here; Phase 3 does the work
   */
  break;

Ce code ne fait rien. On apprend juste que le travail se fait en trois phases et que seule la phase 3 fait le boulot.

Occurence suivante :

/*
 * If we had SET TABLESPACE but no reason to reconstruct tuples,
 * just do a block-by-block copy.
 */
if (tab->newTableSpace)
  ATExecSetTableSpace(tab->relid, tab->newTableSpace);

Là-aussi, peu de choses. On apprend seulement que le « SET TABLESPACE » semble fonctionner dans un mode copie bloc par bloc. Ce qui serait assez logique, tout PostgreSQL fonctionne par bloc.

Occurence suivante :

/*
 * ALTER TABLE SET TABLESPACE
 */
static void
ATPrepSetTableSpace(AlteredTableInfo *tab, Relation rel, char *tablespacename)

Tiens, c'est la fonction appelée à la phase 1. Je ne vais pas mettre tout le code ici, mais voici l'explication du code de cette fonction. La fonction commence par vérifier si le tablespace existe. Dans le cas contraire, elle envoie un message « tablespace "%s" does not exist » avec un niveau ERROR. Ensuite, les droits sont vérifiés. En fait, un seul, celui de création sur le tablespace cible. Enfin, des informations sont sauvegardées pour la fameuse phase 3.

Allez, courage, occurence suivante :

/*
 * Execute ALTER TABLE SET TABLESPACE for cases where there is no tuple
 * rewriting to be done, so we just want to copy the data as fast as possible.
 */
static void
ATExecSetTableSpace(Oid tableOid, Oid newTableSpace)

Cette fois, c'est l'occurence 3 qui fait appel à cette fonction. Pareil, je ne mets pas le code, mais une explication de son travail. Joie, c'est là que le boulot se fait. La fonction commence par poser un verrou AccessExclusiveLock sur la table. Les tables systèmes partagées ne sont pas déplaçables, donc elle vérifie aussi ce cas. Le tablespace cible est vérifié : il ne faut pas que ce soit pg_global, qui est le tablespace des objets systèmes non partagés. La fonction vérifie aussi le statut de la table : si elle est temporaire, elle n'est pas déplaçable. Dernière vérification, le tablespace cible est-il le tablespace où se trouve déjà la table ? Une fois toutes ces vérifications terminées, si le déplacement est possible, le boulot de copie va commencer. Tout d'abord, la fonction force l'enregistrement des blocs modifiés de cette table du cache de PostgreSQL (shared_buffers) sur le disque. Ensuite, la fonction exécute une autre fonction pour chaque fichier de la table source (en effet, une table est stockée sur plusieurs fichiers de 1 Go). Cette autre fonction, de nom copy_relation_data, s'occupe de la copie physique des données. En la parcourant rapidement, on s'aperçoit que le fichier source est copié bloc par bloc, c'est-à-dire 8 Ko par 8 Ko. Chaque copie de bloc est tracée dans les journaux de transactions dans le cas où l'archivage des journaux est activé. Les blocs ne passent pas par le cache disque de PostgreSQL, on ne risque donc pas de dévalider l'entièreté du cache simplement parce qu'on déplace des fichiers.

Faisons un petit résumé. Le fichier backend/commands/tablecmds.c contient toutes ls instructions permettant d'exécuter le déplacement d'une table/index d'un tablespace vers un autre. La copie est elle-même est tout simple : une copie de chaque bloc, un par un.

On sait maintenant comment PostgreSQL réagit à l'ordre de déplacement d'une table. Essayons d'extrapoler. Si on veut déplacer une base de données complète vers un autre tablespace, cela revient à récupérer la liste des tables et index et à les envoyer un par un vers le nouveau tablespace. En fait, plus exactement, cela revient à déplacer les fichiers qui sont dans le tablespace par défaut de la base de données vers le nouveau tablespace. En effet, si d'autres objets ont été déplacés volontairement par l'utilisateur, il ne faut pas les prendre en compte.

Du coup, on peut écrire un pseudo code :

Pour toutes les tables et index compris dans le tablespace par défaut de la base de données ciblée,
 Faire l'équivalent d'un ALTER TABLE la table SET TABLESPACE le nouveau tablespace
Enregistrer que le tablespace par défaut est le tablespace cible.

Donc, le gros du travail est déjà fait. Ça nous simplifie considérablement la tâche. La prochaine étape est donc de faire accepter la nouvelle instruction à PostgreSQL en déclenchant l'exécution d'une fonction. Enfin ! On va écrire un peu de code

.. ou plutôt nouveaux sites web.

Comme l'a annoncé Damien vendredi dernier sur la liste de discussion française, le site www.postgresqlfr.org a été entièrement revu. Plutôt que d'utiliser Drupal pour les news, le forum et certainement d'autres choses, nous sommes passés à plusieurs outils :

• Dotclear pour les news ;
• une page web faite à la main pour l'index des docs, et une génération personnalisée des manuels (à partir de feuilles de style XSLT bien modifiées) ;
• FluxBB pour les forums ;
• dokuwiki pour le wiki de l'association ;
• trac pour les sources des manuels ;
• et enfin planet pour l'agrégateur de blogs.

Ils ont tous le même en-tête, la même feuille de style... on pourrait croire qu'il s'agit d'un seul et même site).

Il a aussi été décidé qu'ils auront chacun leur alias :

• blog.postgresql.fr pour les news ;
• docs.postgresql.fr pour la documentation ;
• forums.postgresql.fr pour les forums ;
• asso.postgresql.fr pour le wiki ;
• planete.postgresql.fr pour la planète des blogueurs PostgreSQL français ;
• etc.

Le boulot qui reste est de transférer le contenu du Drupal dans Dotclear et le wiki. Ça ne devrait pas être long et ça permettra de se débarrasser du Drupal. Joie

Je suis vraiment très content du résultat. Si on regarde finement le codage, il y a encore du travail pour tout factoriser. Mais le résultat est convaincant. J'avais initié le travail sur les nouveaux sites le samedi 6 septembre. 11 jours de travail, à raison d'une ou deux heures en moyenne par jour, c'est rien du tout comparé au résultat. Oui, ça fait un peu auto-congratulation mais j'assume

En tout cas, je vous invite à utiliser ces nouveaux sites et à m'indiquer tout dysfonctionnement. Je vais essayer de réagir promptement à tout problème constaté.

UPDATE: correction du titre (merci Damien )

Bonsoir,

Ça fait un petit moment que ça trotte dans ma petite tête de malade.Pas le fait d'écrire un patch implantant une nouvelle fonctionnalité pour PostgreSQL, mais le fait d'en faire une série. Voilà c'est dit. Ce billet est le premier d'une (pas trop longue, j'espère) série sur le développement d'une nouvelle fonctionnalité pour PostgreSQL.

Évidemment, j'aurais pu me plonger dans la liste des fonctionnalités manquantes, mais j'avais déjà mon idée. Je l'avais depuis le début de l'été, c'est dire Ce projet est donc d'ajouter la possibilité de modifier le tablespace d'une base de données. Je vous entends déjà dire que je suis à côté de mes pompes, que la fonctionnalité des tablespaces est présent depuis la version 8.0. Et vous avez raison. Enfin, pour le deuxième point en tout cas En effet, les tablespaces sont présents depuis la version 8.0. Il est possible de créer, modifier et supprimer un tablespace. Il est possible de créer une relation (donc table ou index) dans un tablespace particulier, il est possible de la déplacer dans un autre. Pareil pour les bases de données. Pareil ? non, pas vraiment. Il est possible de créer une base de données dans un tablespace mais pas de déplacer le contenu d'une base de données existante dans un autre tablespace en une seule commande. J'avoue que quand j'ai appris cela au début de l'été, je suis tombé des nues. Je ne comprenais pas pourquoi on n'avait pas cette fonctionnalité qui semble découler tout logiquement du reste. J'ai une petite idée du pourquoi maintenant, mais je préfère garder le suspens

Donc, voilà. Le but est d'ajouter la fonctionnalité proposée par la commande : ALTER DATABASE nom_base SET TABLESPACE nom_tablespace.

Autant le dire tout de suite, je ne sais pas si je vais arriver réellement à coder cette fonctionnalité. Je ne sais pas non plus si, une fois développée, elle sera acceptée par l'équipe de développement de PostgreSQL. Et en fait, peu importe. Le but est d'apprendre. Il est aussi de montrer comment on peut (facilement) développer une nouvelle fonctionnalité. OK, pour le « facilement », je m'avance certainement un peu

Pourquoi ne pas en avoir fait un article pour GLMF ? tout simplement parce que je veux montrer ma progression au jour le jour, pas à pas. Faire un résumé ne me paraissait pas intéressant. Et dans ce cas, seul un blog permet de faire cela « à ma sauce ». Cela ne m'empêche pas de continuer à écrire pour GLMF. D'ailleurs, Denis vient de m'annoncer que « Opérations de maintenance pour PostgreSQL » sera dans le numéro 109 (à paraître fin septembre), et je suis en train de travailler (humm...) sur le prochain.

Bon, alors, prêt à suivre ?

Jean-Philippe nous a fait une jolie conférence mercredi soir (oui, j'ai du retard, c'est rien de le dire). Il a principalement abordé la traduction d'application, avec un joli programme en python, traduisible avec gettext. J'ai bien aimé. Mon seul regret est qu'il n'a pas parlé de la traduction de document, et notamment de Docbook. C'est d'autant plus dommage que c'est le principal travail de traduc.org. Par contre, il a parlé du glossaire de traduc.org et c'est bien. C'est un outil qui devrait avoir bien plus de publicité. Bref, bonne conf. Les slides seront bientôt sur le site de traduc.org.

On a ensuite été mangé dans un restaurant libanais près de l'Opéra. Excellent. Première fois que j'allais dans un resto libanais et c'est une excellente expérience.

J'ai adoré. Difficile de dire pourquoi en fait. Rob parle d'un petit miracle et je suis vraiment d'accord. Pour Pascale, c'est même providentiel.

Après les avoir cités, je ne sais pas trop quoi dire de plus.

On suit une famille pendant douze ans, mais uniquement sur cinq journées phares de la vie de la famille. On pourrait croire qu'on ne reconnaitra personne, qu'on perdra le fil à chaque transition. Il n'en est rien. On passe d'un membre de la famille à un autre. On voit grandir les enfants, et vieillir grands-parents et parents. Un mariage, des enterrements, des coups de gueule et de l'amour... C'est filmer d'une façon assez déroutante, mais pas désagréable du tout. La bande son est pleine de vieux souvenirs. Tous les acteurs sont excellents, vraiment.

Quitte à me redire, j'ai adoré. À voir absolument.