[gull] pgsql...aaaarh

[Marc SCHAEFER]

On Thu, Jun 16, 2005 at 08:36:15PM +0200, Cedric BRINER wrote:
>  sequence_name | last_value | increment_by |      max_value      | min_value | cache_value | log_cnt | is_cycled | is_called
> ---------------+------------+--------------+---------------------+-----------+-------------+---------+-----------+-----------
>  test_id_seq   |          3 |            1 | 9223372036854775807 |         1 |           1 |      31 | f         | t

http://archives.postgresql.org/pgsql-general/2003-04/msg00327.php

apparemment cela a un rapport avec la préallocation dynamique de numéros
de séquence (optimisation) et à la journalisation.

> a l'air de parfaitemnt fonctionner. Si ``ALTER TABLE new_test RENAME TO test;'' travaille sur les meta-donnees..alors postgres est peut-etre capable de faire des operations atomique sur les metadonnees.!

oui, il fonctionne, mais à ma connaissance, même en PSQL 8, il n'y a pas
de transactionning.

Pour s'en convaincre, avec un autre backend (autre psql), juste au
milieu de la séquence d'instruction SQL du premier backend et avec le
commit, regarder si on voit ce qui a été changé dans la base. Si oui,
on a une fenêtre de vulnérabilité et il serait mieux d'éviter de toucher
aux méta-données sauf si on a une méthode externe pour suspendre les
backends (p.ex. fichier global de lock qui fait attendre les scripts
Perl qui attaquent la base).